Hi Rob,
On Mon, Feb 18, 2013 at 19:17:29, Rob Herring wrote:
On 02/18/2013 12:30 AM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one core, this is
Hi,
On Tue, Feb 19, 2013 at 11:23:14AM +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
Hi,
On Tue, Feb 19, 2013 at 11:23:15AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be
Hi Felipe,
On Mon, Feb 18, 2013 at 23:52:40, Balbi, Felipe wrote:
On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
+ uart1: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ clock-frequency = 4800;
+
On Tue, Feb 19, 2013 at 10:10:17AM +0100, Mohammed, Afzal wrote:
Hi Felipe,
On Mon, Feb 18, 2013 at 23:52:40, Balbi, Felipe wrote:
On Mon, Feb 18, 2013 at 05:08:16PM +0530, Afzal Mohammed wrote:
+ uart1: serial@44e09000 {
+ compatible =
On Monday 18 February 2013 05:05 PM, Afzal Mohammed wrote:
(Resending, since it seems, LAKML doesn't accept patches with subject
prefix only as RFC, but requires PATCH prefix also)
Hi,
This series adds minimal support to boot Linux on platforms having
AM43 based SoC's.
This is being sent as
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one core, this is being registered as per
existing boot flow, with a
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote:
Add an optional property to find clock-frequency from DT. This helps
as a fallback mechanism in case there is no representation of clock
tree in DT.
Signed-off-by: Afzal Mohammed af...@ti.com
---
This won't work always because twd
On Monday 18 February 2013 05:06 PM, Afzal Mohammed wrote:
Return percpu clock event on local timer register. It is the boot cpu
that calls this and it can use the returned percpu clock event to
register a clock event in the case of SMP configuration with one core.
SMP configuration with 1 core
OMAP's debugfs interface creates one file
for each signal in the mux table, such file
provides a read method but didn't provide
read permission. Fix it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/mux.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
nothing from linux/debugfs.h is used on
voltage.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/voltage.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3ac8fe1..595bf1a 100644
---
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote:
Selecting DEBUG_AM33XXUART1 routes low level debug messages to first
UART instance of AM335x based SoC's. This selection is valid for
upcoming AM43 based SoC's too. Make this information available upon
configuring.
Signed-off-by: Afzal
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9
based (SMP configuration with 1 core).
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/Kconfig | 11 +++
1 file changed, 11 insertions(+)
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z�
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
Describe minimal DT boot machine details for AM43 based SoC's. AM43
family of SoC's are ARM Cortex-A9 based with one core in SMP
configuration. Low level debug could be achieved by selecting
DEBUG_AM33XXUART1. To boot AM43 SoC, this
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates an AM43 SoC, add DT build support.
As bootloader is not used, bootargs is
Hi Matthias,
On 02/15/2013 04:59 PM, Matthias Brugger wrote:
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
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without
Hi Santosh,
On Tue, Feb 19, 2013 at 16:05:22, Shilimkar, Santosh wrote:
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates
On Tue, Feb 19, 2013 at 03:57:07PM +0530, Santosh Shilimkar wrote:
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9
based (SMP configuration with 1 core).
Signed-off-by: Afzal Mohammed af...@ti.com
---
On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote:
Hi Santosh,
On Tue, Feb 19, 2013 at 16:05:22, Shilimkar, Santosh wrote:
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To
On Tuesday 19 February 2013 04:26 PM, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 03:57:07PM +0530, Santosh Shilimkar wrote:
On Monday 18 February 2013 05:08 PM, Afzal Mohammed wrote:
Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9
based (SMP configuration with 1 core).
On Tuesday 19 February 2013 04:00 PM, Mohammed, Afzal wrote:
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Indeed. Tony
Hi Santosh,
On Tue, Feb 19, 2013 at 16:30:13, Shilimkar, Santosh wrote:
On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote:
SoC support is already added in patch 7/8. This is board (which doesn't
exist now) support, hence a pre-silicon temporary one to validate it.
I mean we can
On Tuesday 19 February 2013 04:33 PM, Mohammed, Afzal wrote:
Hi Santosh,
On Tue, Feb 19, 2013 at 16:30:13, Shilimkar, Santosh wrote:
On Tuesday 19 February 2013 04:22 PM, Mohammed, Afzal wrote:
SoC support is already added in patch 7/8. This is board (which doesn't
exist now) support, hence
Hi Santosh,
On Tue, Feb 19, 2013 at 15:39:32, Shilimkar, Santosh wrote:
After looking at the specs, you don't need the SMP mode since ACP
isn't being used.
TWD use for AM437x is also limited because these times stops in
low power sates and there you will need broad-cast mechanism which
Hi,
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or
On 2013-02-18 16:30, Ruslan Bilovol wrote:
So, I'm still inclined to say that we shouldn't merge this.
Thanks for explanation.
Do you have some plan when DSS will be ready to port this driver?
(3.10, 3.11 or later)?
When it's ready =). The work depends also on common display framework,
Hi,
On Mon, Feb 18, 2013 at 05:06:39PM +0530, Afzal Mohammed wrote:
@@ -315,6 +315,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
+ struct clock_event_device *evt;
On Tue, Feb 19, 2013 at 03:44:14PM +0530, Santosh Shilimkar wrote:
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases - secondary cpu's as well as boot
cpu's having more than one
On Tuesday 19 February 2013 05:44 PM, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 03:44:14PM +0530, Santosh Shilimkar wrote:
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote:
Register percpu local timer for scheduler tick in the case of one core
SMP configuration. In other cases -
On Tuesday 19 February 2013, kishon wrote:
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY
drivers
to create/destroy a PHY and APIs for the PHY
This patch series adds low power transition support for OMAP NAND driver.
With recent driver conversion of GPMC to platform_driver, pm_runtime calls
can be used to handle module enable disable of GPMC. This is taken care
patch #1.
patch #2 is for GPMC suspend/resume support.
This includes low
On Wed, Feb 13, 2013 at 18:13:03, Russell King - ARM Linux wrote:
On Wed, Feb 13, 2013 at 11:42:01AM +, Philip, Avinash wrote:
On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
+static int
Support for pm_runtime add to GPMC driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c57f81..b1cd6c1 100644
---
With GPMC converted to platform driver recently, adds low power
transition support in driver itself.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
Module disable enable added using pm_runtime support.
arch/arm/mach-omap2/gpmc.c | 20
1
In low power modes of AM335X platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ELM driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes Since v2:
- Removes wait queue mechanism. The order of device creation ensures
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that
The .init_late callback for OMAP3 has been missing for DT
builds, which causes a lot of late PM initializations to
be missed in turn.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c |2 ++
1 file changed, 2 insertions(+)
diff --git
Hi,
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, kishon wrote:
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs
On Tuesday 19 February 2013 06:28 PM, Rajendra Nayak wrote:
The .init_late callback for OMAP3 has been missing for DT
builds, which causes a lot of late PM initializations to
be missed in turn.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Hi,
On Tuesday 19 February 2013 06:26 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a
On Tuesday 19 February 2013, kishon wrote:
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
Currently drivers/phy and drivers/net/phy are independent and are not
related to each other. There are some fundamental differences on how
these frameworks work. IIUC, the
Hi,
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
Currently drivers/phy and drivers/net/phy are independent and are not
related to each other. There are
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch the SYSCONFIG register
Philip Avinash avinashphi...@ti.com writes:
With GPMC converted to platform driver recently, adds low power
transition support in driver itself.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
Module disable enable added using pm_runtime support.
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
It's a fine line, but I think a phy is something that resembles a
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are allowed. That would require adding
a function pointer to struct
On Tue, Feb 19, 2013 at 03:30:01PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are
On Tue, Feb 19, 2013 at 03:28:17PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
On 02/19/2013 04:05 PM, Felipe Balbi wrote:
Hi,
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
Currently drivers/phy and drivers/net/phy are independent and are
Hi,
On Tue, Feb 19, 2013 at 05:07:09PM +0100, Marc Kleine-Budde wrote:
On 02/19/2013 04:05 PM, Felipe Balbi wrote:
Hi,
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
On Tue, Feb 19, 2013 at 03:30:01PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in
* Paul Walmsley p...@pwsan.com [130219 07:30]:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed
Hi,
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need
* Felipe Balbi ba...@ti.com [130219 09:01]:
Hi,
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
If you want such things as pci_enable_device(), then what you're actually
asking for is omap_enable_device() for OMAP devices. OMAP devices are
already specific
Hi,
On Tue, Feb 19, 2013 at 09:43:36AM -0800, Tony Lindgren wrote:
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the
[...]
Just to recap what we've discussed earlier, the reasons why we want
reset and idle functions should be in the driver specific header are:
1. There's often driver specific logic needed in addition to the
syconfig tinkering in the reset/idle functions.
It's been a while since
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 10:26]:
On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
If you want such things as pci_enable_device(), then what you're actually
asking for is
Hi,
On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
[ ... ]
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed in certain error recovery
scenarios.
Hi,
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of huge churn, think again. Remember, churn is evil. I've
complained to
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
[ ... ]
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed
Hi,
On Tue, Feb 19, 2013 at 11:50:37AM -0800, Kevin Hilman wrote:
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed in certain error recovery
scenarios.
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Feb 19, 2013 at 11:50:37AM -0800, Kevin Hilman wrote:
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed in
On Friday 15 February 2013, Tony Lindgren wrote:
Hi Arnd Olof,
Roger Quadros reworked the OMAP USB patches that were causing
a conflict in Linux next and we requested to be dropped from
Linux next and reworked to remove the dependencies between
core SoC code and the driver code.
Below
* Arnd Bergmann a...@arndb.de [130219 13:34]:
On Friday 15 February 2013, Tony Lindgren wrote:
Hi Arnd Olof,
Roger Quadros reworked the OMAP USB patches that were causing
a conflict in Linux next and we requested to be dropped from
Linux next and reworked to remove the dependencies
* Felipe Balbi ba...@ti.com [130219 11:47]:
Hi,
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of huge churn, think again.
Hi,
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of
* Felipe Balbi ba...@ti.com [130219 14:26]:
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
..that means massive amount of churn in the board-*.c files to convert
them to various init functions to be called from board-generic.c and
removing the ones that are working with
Hi,
On Tue, Feb 19, 2013 at 02:31:28PM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130219 14:26]:
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
..that means massive amount of churn in the board-*.c files to convert
them to various init functions to be
Hi Jon,
On Fri, Feb 15, 2013 at 02:08:08PM -0600, Jon Hunter wrote:
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
On Wednesday 20 February 2013 12:46 AM, Kevin Hilman wrote:
[...]
Just to recap what we've discussed earlier, the reasons why we want
reset and idle functions should be in the driver specific header are:
1. There's often driver specific logic needed in addition to the
syconfig tinkering
74 matches
Mail list logo
