RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic.
-Original Message- From: Anand Gadiyar [mailto:gadi...@ti.com] Sent: Saturday, January 29, 2011 2:19 AM To: Sricharan R; linux-omap@vger.kernel.org Cc: Santosh Shilimkar; t...@atomide.com; p...@pwsan.com Subject: RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic. sricharan wrote: 1) All the pads of a hwmod for the device are classified as static/dynamic. If a pad requires remuxing during the device transitions between enable/idle transitions then it is added to the dynamic list, static otherwise. 2) Both the static/dynamic pads of a hwmod are initialised when the device gets enabled. When the device transitions between enable/idle the dynamic pads are remuxed and static pads are skipped. 3) When the driver gets removed both the static and the dynamic pads are muxed to safe mode as default. I haven't taken a look at the code. I do have a few concerns (which may really be non-issues, but I'm pointing them out anyway): - Not all pads have a safe mode. --- And why would you want statically muxed pads to be remuxed into safe mode anyway? What is the advantage of such a change, as against leaving them in a functional mode? There is an option to mux the pads to different mode than safe mode when the driver is removed. Those which do not specify are put to safe mode. With safe mode, the pins becomes a input with no functional interface connected to it. This avoids the either omap or outside device seeing any false logic from the pin. - Many signals are muxed on more than one pad. - Many peripherals need pads to be configured in different mux modes depending on the way a board is wired up. With this, moving pad info to hwmod databases does not sound useful to me. Maybe I do not understand the need for this change, in place of what we have today. The structure for containing the mux data is part of hwmod for the device. The hwmod is not static and it is dynamically populated during the device init, with the data being passed from board files if it is different across boards. The device state transitions (enable/idle) passes the through the hwmod layer, which takes caring of muxing the pins right way for each transition. This helps to mux correctly the 1) shared pins 2) Initialsing the pads 3) Remux only pads that require change during enable/idle transitions. 4) Put the pads to safemode( default) when the driver is unplugged. - Anand -- 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
RE: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial pads
-Original Message-
From: Anand Gadiyar [mailto:gadi...@ti.com]
Sent: Saturday, January 29, 2011 2:23 AM
To: Sricharan R; linux-omap@vger.kernel.org
Cc: Santosh Shilimkar; t...@atomide.com; p...@pwsan.com
Subject: RE: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial
pads
Sricharan wrote:
Use the mux framework to initialise the serial pads.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 72
+++-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b43e3ff..9688ea9 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,83 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+{ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .flags = OMAP_DEVICE_PAD_REMUX_IDLE,
+ .idle = OMAP_MUX_MODE7,
+},
+{ .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+{ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial4_pads[] __initdata = {
+{ .name = uart4_rx.uart4_rx,
+.enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_board_data serial2_data = {
+.id = 1,
+.pads = serial2_pads,
+.pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+.id = 2,
+.pads = serial3_pads,
+.pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static struct omap_board_data serial4_data = {
+.id = 3,
+.pads = serial4_pads,
+.pads_cnt = ARRAY_SIZE(serial4_pads),
+};
+
+static inline void board_serial_init(void)
+{
+omap_serial_init_port(serial2_data);
+omap_serial_init_port(serial3_data);
+omap_serial_init_port(serial4_data);
+}
#else
#define board_mux NULL
+
+static inline void board_serial_init(void)
+{
+omap_serial_init();
+}
#endif
static void __init omap4_panda_init(void)
You are changing the behavior with this patch.
Original code configured all 4 UARTs, while it
appears that your patch changes this to skip UART1.
This is not explained in the changelog. Is this
a deliberate change? Why would you want to do this?
I see that UART1 is not muxed out and all uart1 pads
are all used for alternate functionalities.
So I did not initialize UART1.
However, there was a mistake with serial2 mux
which I have corrected in version2.
- Anand
--
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
RE: [PATCH v2 4/5] omap4: board-omap4panda: Initialise the serial pads
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Wednesday, February 02, 2011 6:42 AM
To: sricharan
Cc: linux-omap@vger.kernel.org; santosh.shilim...@ti.com;
t...@atomide.com;
p...@pswan.com; gadi...@ti.com; b-cous...@ti.com
Subject: Re: [PATCH v2 4/5] omap4: board-omap4panda: Initialise the
serial
pads
sricharan r.sricha...@ti.com writes:
Removed the remux flags for serial2 cts which was
kept for testing. Passed the serial data to serial
init.
This is a description of what changed since v1, not a description of the
patch. This kind of version history should go after the '---' for the
benefit of reviewers. Please add a description of this patch here.
Ok. I will correct this and send.
I will take this for my future patches also.
Tested this on omap4panda.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 72
+++-
1 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-
omap2/board-omap4panda.c
index b43e3ff..1c65420 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,81 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+{ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+{ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial4_pads[] __initdata = {
+{ .name = uart4_rx.uart4_rx,
+.enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_board_data serial2_data = {
+.id = 1,
+.pads = serial2_pads,
+.pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+.id = 2,
+.pads = serial3_pads,
+.pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static struct omap_board_data serial4_data = {
+.id = 3,
+.pads = serial4_pads,
+.pads_cnt = ARRAY_SIZE(serial4_pads),
+};
+
+static inline void board_serial_init(void)
+{
+omap_serial_init_port(serial2_data);
+omap_serial_init_port(serial3_data);
+omap_serial_init_port(serial4_data);
+}
#else
#define board_mux NULL
+
+static inline void board_serial_init(void)
+{
+omap_serial_init();
+}
#endif
As Anand pointed out in your earlier version, this patch also contains
a functional change, namely not initializing UART1.
In addition to Anand's, it introduces a potentially confusing and
unexpected difference with and without CONFIG_MUX. When CONFIG_MUX is
enabled, you get UART2,3 4 initialized, and with !CONFIG_MUX you all
UARTs.
In my opinion, this patch should continue to initialize all UARTs. If
you want to leave out the init of UART1, introduce it as a separate
patch please.
Ok. Actually as I said earlier UART1 though initialized
Is not getting muxed out. I can see that all the UART1
pads are used for alternate functionalities. But as you said
the initialization should be same for both CONFIG_MUX and
!CONFIG_MUX . So I will remove the initialization of UART1
and will send this as a separate patch.
Kevin
static void __init omap4_panda_init(void)
@@ -389,7 +457,7 @@ static void __init omap4_panda_init(void)
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
-omap_serial_init();
+board_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop
transceiver
*/
usb_nop_xceiv_register();
--
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
RE: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
Hi Sricharan,
On 9/8/2011 7:22 AM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
The address space count API returns the number of address space
entries for a hwmod including a additional null value present in the
address space structure introduced recently.
That's a minor nit, but you might give the commit you are referencing
here.
Ok i will mention the below in detail and resend.
commit 78183f3fdf76f422431a81852468be01b36db325
The devices which
have multiple hwmods and use device_build_ss are broken with this,
as their address resources are populated with a extra null value,
subsequently the probe fails. So fix the API not to add the null value.
It seems that in every cases, we are adding an extra null resource for
nothing. But it is true that will not crash if the driver is just
expecting an unique entry.
What is happening with multiple hwmods is probably the introduction of
that extra null resource in the middle of the real ones, hence shifting
the resource index?
You might give more details here.
That is exactly correct.
So because of the introduction of the null structure in the middle,
the subsequent resource indexes gets shifted by one. So the
original index used by the drivers in those places would return a NULL
resource now, hence the problem.
Signed-off-by: sricharanr.sricha...@ti.com
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..32a0f48a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,9 +791,11 @@ static int _count_ocp_if_addr_spaces(struct
omap_hwmod_ocp_if *os)
if (!os || !os-addr)
return 0;
-do {
-mem =os-addr[i++];
-} while (mem-pa_start != mem-pa_end);
+mem =os-addr[i];
+
+while (mem-pa_start != mem-pa_end) {
+mem =os-addr[++i];
+};
return i;
Cannot you just do return i - 1?
Right. That was the first idea.
But after some discussion concluded that
right way is to, not to take in to account, the
null structure itself, rather than incrementing and
decrementing.
Regards,
Benoit
Thanks,
Sricharan
--
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
--
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
RE: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
[...]
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Thursday, September 08, 2011 2:35 PM
To: Sricharan R
Subject: Re: [PATCH 1/8] OMAP: hwmod: Fix the addr spaces count API.
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..32a0f48a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -791,9 +791,11 @@ static int _count_ocp_if_addr_spaces(struct
omap_hwmod_ocp_if *os)
if (!os || !os-addr)
return 0;
- do {
- mem =os-addr[i++];
- } while (mem-pa_start != mem-pa_end);
+ mem =os-addr[i];
+
This extran line isn't needed Sricharan.
Will correct this, along with benoit's commmets.
Thanks,
Sricharan
--
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
Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
Hi,
A kernel crash is observed on 3.1rc4 kernel when HIGHMEM is enabled and
kernel is booted with a NFS on omap4430sdp. The issue happens in the
below
scenario.
In file net/sunrpc/xprtsock.c,
static int xs_send_pagedata( xxx, struct xdr_buf *xdr, ..)
{
Struct page **ppage;
.
ppage = xdr-pages + (base PAGE_SHIFT);
err = sock-ops-sendpage(sock, *ppage, base, len, flags);
...
}
1) In the above piece of code, the *ppage value from
ops-sendpage function is finally passed on to Kmap by the lower
level code to get the virtual address of the page.
2) In some corner cases the value of *ppage pointer is NULL.
3) When highmem is enabled and a NULL pointer is passed to
Kmap, then kmap finally crashes. But in the case when highmem
is disabled, then kmap returns a junk value for NULL pointer.
Highmem Enabled , kmap( NULL )- kernel crashes.
Highmem disabled, kmap( NULL )- junk value is
returned.
Subsequently this message
is observed on
the console.
RPC call returned error 14
4) Now the question is why is the value of *ppage = NULL is
passed
from the above piece of code to lower layers.
Should that not have handled *ppage = NULL? and kmap should not
have received a NULL pointer?
Thanks,
Sricharan
--
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
RE: Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
Hi Trond, [] 1) In the above piece of code, the *ppage value from ops- sendpage function is finally passed on to Kmap by the lower level code to get the virtual address of the page. 2) In some corner cases the value of *ppage pointer is NULL. 3) When highmem is enabled and a NULL pointer is passed to Kmap, then kmap finally crashes. But in the case when highmem is disabled, then kmap returns a junk value for NULL pointer. Highmem Enabled , kmap( NULL )- kernel crashes. Highmem disabled, kmap( NULL )- junk value is returned. Subsequently this message is observed on the console. RPC call returned error 14 4) Now the question is why is the value of *ppage = NULL is passed from the above piece of code to lower layers. Should that not have handled *ppage = NULL? and kmap should not have received a NULL pointer? I wouldn't expect *ppage to be NULL under any circumstances, so I'm really curious as to what is happening here. Could you perhaps add a printk() to that section of code to print out the values of 'xdr-page_base', 'xdr-page_len', 'len' and 'remainder' in the case where *ppage == NULL? Thanks for the response. I added a printk just before err = sock-ops-sendpage(sock, *ppage, base, len, flags); So here are values when *ppage is NULL. xdr-page_base= 0xCE9 xdr-page_len=0x400 len=0xE9 remainder=0x0. Thanks, Sricharan -- 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
RE: Regression seen when HIGHMEM enabled with NFS on 3.1rc4 kernel
[..] Can you please tell me what the mount options are for this setup? I'm guessing you've got wsize=1024, in which case, can you please try the following patch? The mount options for nfs is rw. Yes, in my setup wsize=1024 when the issue happened. I tried your patch and I was not able to see the issue after that, where as in the other case the issue happened quite frequently. So I think that the patch fixes the issue. Thanks a lot for your help. Cheers Trond 8--- -- - From 7b4a9c76b55dd254431902552528137a2ea5e55d Mon Sep 17 00:00:00 2001 From: Trond Myklebust trond.mykleb...@netapp.com Date: Mon, 12 Sep 2011 11:47:53 -0400 Subject: [PATCH] NFS: Fix a typo in nfs_flush_multi Fix a typo which causes an Oops in the RPC layer, when using wsize 4k. Signed-off-by: Trond Myklebust trond.mykleb...@netapp.com --- fs/nfs/write.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/nfs/write.c b/fs/nfs/write.c index b39b37f..c9bd2a6 100644 --- a/fs/nfs/write.c +++ b/fs/nfs/write.c @@ -958,7 +958,7 @@ static int nfs_flush_multi(struct nfs_pageio_descriptor *desc, struct list_head if (!data) goto out_bad; data-pagevec[0] = page; - nfs_write_rpcsetup(req, data, wsize, offset, desc-pg_ioflags); + nfs_write_rpcsetup(req, data, len, offset, desc-pg_ioflags); list_add(data-list, res); requests++; nbytes -= len; -- 1.7.6 -- Trond Myklebust Linux NFS client maintainer NetApp trond.mykleb...@netapp.com www.netapp.com -- 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
RE: [PATCH] ARM: OMAP2+: TEMP: Round of the carve out memory requested to section_size
[..] memblock_steal tries to reserve physical memory during boot. When the requested size is not aligned on the section size then, the remaining memory available for lowmem becomes unaligned on the section boundary. There is a issue with this, which is discussed in the thread below. https://lkml.org/lkml/2012/6/28/112 The final conclusion from the thread seems to be align the memblock_steal calls on the SECTION boundary. Signed-off-by: R Sricharan r.sricha...@ti.com Why is the TEMP in the subject line. From patch it doesn't be temporary version. Can you please clarify that ? Oops, that was a mistake. Reposted by correcting it. Thanks, Sricharan -- 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
RE: [Q] No message from Kernel (Howto start debug?)
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Arno Steffen Sent: Thursday, July 28, 2011 6:45 PM To: linux-omap@vger.kernel.org Subject: [Q] No message from Kernel (Howto start debug?) Maybe you are so kind to give me a hint: Try to migrate from Kernel 33 to 37. Currently I don't see any message after Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... If you are stuck with Starting kernel ... and do not see Uncompressing Linux... done, booting the kernel means could have crashed before your kernel in case of uImage. Check the arch_id that you are passing from the bootloader. Also enable early printk. From what I understand kernel starts with start_kernel()). What is best way to find out which part is failing? At which point I do a printk to see what's going on, or at least set a GPIO Pin of the processor? How to debug without any external tools like JTAG. -- 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 Thanks, Sricharan -- 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
RE: [PATCH 0/4] ARM: OMAP2+: Misc cleanup part2
-Original Message- From: R Sricharan [mailto:r.sricha...@ti.com] Sent: Thursday, May 10, 2012 10:37 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com; p...@pswan.com Subject: [PATCH 0/4] ARM: OMAP2+: Misc cleanup part2 This is a continuation of the previous cleanup series from santosh.shilim...@ti.com [1]. Patches are outcome of the OMAP5 review suggestions from Tony/Benoit/Santosh/Rajendra. [1] http://www.spinics.net/lists/linux-omap/msg69730.html R Sricharan (4): ARM: OMAP2+: Introduce CONFIG_SOC_HAS_OMAP_DPLL macro ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak. ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. Forgot to add the below reviewed-by tag. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, Sricharan -- 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
RE: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
Hi Tony, -Original Message- From: R Sricharan [mailto:r.sricha...@ti.com] Sent: Thursday, May 03, 2012 12:56 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; santosh.shilim...@ti.com; t...@atomide.com; b-cous...@ti.com; r.sricha...@ti.com Subject: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. OMAP5 V2 series is ready with all comments addressed, but I have below dependencies to be merged to apply my series against your cleanup-soc branch 1) git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 2) git://git.pwsan.com/linux-2.6 hwmod_data_cleanup_3.5 3) https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup 4) http://www.spinics.net/lists/arm-kernel/msg174461.html Can you please let me know how you want me to prepare the series with these dependencies. Thanks, Sricharan -- 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
RE: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi Paul, On Thu, 10 May 2012, R Sricharan wrote: Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. Thanks. I will pick up your series. Thanks, Sricharan -- 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
RE: [PATCH-V2 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Vaibhav, This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... But what happens when a single kernel is built that has support for an SoC with an SDRC (OMAP4) and one that doesn't (AM33xx)? As such Nothing...I looking into this direction while implementing. In that case, sdrc.c file will be compiled in and execution will jump to omap2_set_globals_sdrc(). But inside this function, we are already checking whether the omap2_globals-sdrc and omap2_globals-sms for NULL and then use it. And function omap2_sdrc_init() is also depends on machine, so in case of Am33xx, it won't get into sdrc execution at all. And in case of omap4, it will. Then why bother with the #ifdef at all? If it already safe to call on all SoCs, just get rid of the #ifdef all together. Kevin, sdrc.o target gets built only as omap-2-3-common, this will not get built for omap4, am33xx, ti81xx, etc... So in order to avoid build break, you have to have some mechanism, and that's where we need to create config option dependent on platform. Another better way of handling this is adding __weak function. What's your opinion on this? Then how about just allowing to compile for all omap2/3/4 ? Thanks, Sricharan -- 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
RE: [PATCH 0/5] omap2+: mux: Add support for static and dynamic pads.
Hi Tony, -Original Message- From: sricharan [mailto:r.sricha...@ti.com] Sent: Friday, January 28, 2011 10:38 AM To: r.sricha...@ti.com; linux-omap@vger.kernel.org Cc: santosh.shilim...@ti.com; t...@atomide.com; p...@pwsan.com Subject: [PATCH 0/5] omap2+: mux: Add support for static and dynamic pads. 1) The support to add the pad data to the device hwmod entry and to use it to dynamically configure the pads based on the state of the hwmod is already present. 2) But using that for pads that requires only initialisation and not dynamic remux, brings in a overhead to iterate over all the hwmod signals of the device for every device enable/idle transitions. 3) By seperating the pads that requires remux as dynamic and the ones that do not as static the above overhead is avoided. 4) This way the static and dynamic pads are initialised, and only dynamic pads are taken for remuxing. sricharan (5): omap2+: mux: Seperate the pads of a hwmod as static and dynamic. omap4: board-4430sdp: Initialise the serial pads omap3: board-3430sdp: Initialise the serial pads. omap4: board-omap4panda: Initialise the serial pads omap2+: board-n8x0: Change the flags for the serial pads. Any comments on this?? Thanks, Sricharan -- 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
RE: OMAP4 Mux FW question
Hi Archit, Those control registers are not a part of the mux list. So the mux framework does not support configuring them. Only the pad mux registers are configured. Thanks, Sricharan -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of archit taneja Sent: Thursday, February 17, 2011 4:06 PM To: Benoit Cousson; linux-omap@vger.kernel.org Subject: OMAP4 Mux FW question Hi, Does the current Mux Framework support configuration of Registers like CONTROL_DSIPHY, CONTROL_USB etc in SYSCTRL_PADCONF_CORE in OMAP4? Could someone guide me to an example? Thanks, Archit -- 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 -- 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
RE: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod database.
Hi Benoit,
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Monday, February 21, 2011 8:10 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan
Subject: Re: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod
database.
Hi Sricharan,
On 2/21/2011 2:46 PM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
Add the error log registers, irqs of the l3 interconnect to the
hwmod data. The hwmod change is aligned with Benoit Cousson.
The change is almost aligned with Benoit Cousson :-)
The subject should be something like: omap4: hwmod data: Add address
space and irq in L3 hwmod
There is no errolog data in that patch. The changelog should be updated
too.
Ok. I will change the subject and the change log as well.
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Signed-off-by: sricharanr.sricha...@ti.com
Tested-by: sricharanr.sricha...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index c2806bd..95001d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -229,11 +229,37 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L3 target configuration and error log registers */
+static struct omap_hwmod_irq_info omap44xx_l3_targ_irqs[] = {
+{ .irq = 9 + OMAP44XX_IRQ_GIC_START },
+{ .irq = 10 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_l3_targ_addrs[] = {
+{
+.pa_start = 0x4400,
+.pa_end = 0x4410,
+.flags = ADDR_TYPE_RT,
+},
+{
+.pa_start = 0x4480,
+.pa_end = 0x4490,
+.flags = ADDR_TYPE_RT,
+},
+{
+.pa_start = 0x4500,
+.pa_end = 0x4510,
+.flags = ADDR_TYPE_RT,
IIRC, we do have one address space per l3_main instance, and we do have
3 instances and thus 3 hwmods.
So you should potentially duplicate the code below at hwmod structure
level and not only at address space level.
In that case, you will re-group the 3 instances in only one omap_device.
For the IRQ, in theory we should duplicate the same entry 3 times just
in case someone want to use only the second instance. But, I'm still not
convinced this is the right thing to do... so let's keep it only for
l3_main_1 for the moment.
Ok.
Regards,
Benoit
--
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
RE: [PATCH 1/6] omap3: hwmod_data: Add l3 error log data to hwmod database.
Hi Benoit,
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Monday, February 21, 2011 7:16 PM
To: linux-omap@vger.kernel.org
Cc: ba...@ti.com; b-cous...@ti.com; r.sricha...@ti.com; Santosh Shilimkar
Subject: [PATCH 1/6] omap3: hwmod_data: Add l3 error log data to hwmod
database.
From: sricharan r.sricha...@ti.com
Add the error log registers, irqs of the l3 interconnect to the
hwmod data. The hwmod changes are aligned with Benoit Cousson.
Updated the patch as per your comments for omap3.
[PATCH v2 1/6] omap3: hwmod_data: Add address space and irq in L3 hwmod.
Add the address spaces, irqs of the l3 interconnect to the hwmod data. The
hwmod changes are aligned with Benoit Cousson.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: sricharan r.sricha...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 22 --
arch/arm/plat-omap/include/plat/irqs.h |2 ++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..9a8f799 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -72,10 +72,26 @@ static struct omap_hwmod_ocp_if
omap3xxx_l3_main__l4_per = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L3 taret configuration and error log registers */ static struct
+omap_hwmod_irq_info omap3xxx_l3_targ_irqs[] = {
+ { .irq = INT_34XX_L3_DBG_IRQ },
+ { .irq = INT_34XX_L3_APP_IRQ },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_l3_targ_addrs[] = {
+ {
+ .pa_start = 0x6800,
+ .pa_end = 0x6810,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
/* MPU - L3 interface */
static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
- .master = omap3xxx_mpu_hwmod,
- .slave = omap3xxx_l3_main_hwmod,
+ .master = omap3xxx_mpu_hwmod,
+ .slave= omap3xxx_l3_main_hwmod,
+ .addr = omap3xxx_l3_targ_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_l3_targ_addrs),
.user = OCP_USER_MPU,
};
@@ -94,6 +110,8 @@ static struct omap_hwmod_ocp_if
*omap3xxx_l3_main_masters[] = { static struct omap_hwmod
omap3xxx_l3_main_hwmod = {
.name = l3_main,
.class = l3_hwmod_class,
+ .mpu_irqs = omap3xxx_l3_targ_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_l3_targ_irqs),
.masters= omap3xxx_l3_main_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_main_masters),
.slaves = omap3xxx_l3_main_slaves,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 2910de9..e614de1 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -315,6 +315,8 @@
#define INT_34XX_SSM_ABORT_IRQ 6
#define INT_34XX_SYS_NIRQ 7
#define INT_34XX_D2D_FW_IRQ8
+#define INT_34XX_L3_DBG_IRQ 9
+#define INT_34XX_L3_APP_IRQ 10
#define INT_34XX_PRCM_MPU_IRQ 11
#define INT_34XX_MCBSP1_IRQ16
#define INT_34XX_MCBSP2_IRQ17
--
1.7.0.4
Thanks,
sricharan
--
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
RE: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod database.
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Wednesday, February 23, 2011 11:09 AM
To: Benoit Cousson; Santosh Shilimkar
Cc: 'linux-omap@vger.kernel.org'; Felipe Balbi
Subject: RE: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod
database.
Hi Benoit,
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Monday, February 21, 2011 8:10 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan
Subject: Re: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to
hwmod
database.
Hi Sricharan,
On 2/21/2011 2:46 PM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
Add the error log registers, irqs of the l3 interconnect to the
hwmod data. The hwmod change is aligned with Benoit Cousson.
The change is almost aligned with Benoit Cousson :-)
The subject should be something like: omap4: hwmod data: Add address
space and irq in L3 hwmod
There is no errolog data in that patch. The changelog should be updated
too.
Ok. I will change the subject and the change log as well.
Here is the updated patch as per your suggestion.
---
[PATCH v2 4/6] omap4: hwmod_data: Add address space and irq in L3 hwmod.
Add the address spaces, irqs of the l3 interconnect to the hwmod data. The
hwmod change is aligned with Benoit Cousson.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: sricharan r.sricha...@ti.com
Tested-by: sricharan r.sricha...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
changed the subject line and the changelog
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..95001d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -229,11 +229,37 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L3 target configuration and error log registers */ static struct
+omap_hwmod_irq_info omap44xx_l3_targ_irqs[] = {
+ { .irq = 9 + OMAP44XX_IRQ_GIC_START },
+ { .irq = 10 + OMAP44XX_IRQ_GIC_START }, };
+
+static struct omap_hwmod_addr_space omap44xx_l3_targ_addrs[] = {
+ {
+ .pa_start = 0x4400,
+ .pa_end = 0x4410,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ .pa_start = 0x4480,
+ .pa_end = 0x4490,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ .pa_start = 0x4500,
+ .pa_end = 0x4510,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
/* mpu - l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 = {
.master = omap44xx_mpu_hwmod,
.slave = omap44xx_l3_main_1_hwmod,
.clk= l3_div_ck,
+ .addr = omap44xx_l3_targ_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_l3_targ_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -248,6 +274,8 @@ static struct omap_hwmod_ocp_if
*omap44xx_l3_main_1_slaves[] = { static struct omap_hwmod
omap44xx_l3_main_1_hwmod = {
.name = l3_main_1,
.class = omap44xx_l3_hwmod_class,
+ .mpu_irqs = omap44xx_l3_targ_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_targ_irqs),
.slaves = omap44xx_l3_main_1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
--
1.7.0.4
Thanks,
Sricharan
--
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
RE: [PATCH 1/6] omap3: hwmod_data: Add l3 error log data to hwmod database.
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Monday, February 21, 2011 7:16 PM
To: linux-omap@vger.kernel.org
Cc: ba...@ti.com; b-cous...@ti.com; r.sricha...@ti.com; Santosh Shilimkar
Subject: [PATCH 1/6] omap3: hwmod_data: Add l3 error log data to hwmod
database.
From: sricharan r.sricha...@ti.com
Add the error log registers, irqs of the l3 interconnect to the
hwmod data. The hwmod changes are aligned with Benoit Cousson.
Changed as per your comments for omap3.
---
[PATCH v2 1/6] omap3: hwmod_data: Add address space and irq in L3 hwmod.
Add the address spaces, irqs of the l3 interconnect to the
hwmod data. The hwmod changes are aligned with Benoit Cousson.
Signed-off-by: sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: sricharan r.sricha...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
changed the subject line and changelog.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 22 --
arch/arm/plat-omap/include/plat/irqs.h |2 ++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..9a8f799 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -72,10 +72,26 @@ static struct omap_hwmod_ocp_if
omap3xxx_l3_main__l4_per = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L3 taret configuration and error log registers */
+static struct omap_hwmod_irq_info omap3xxx_l3_targ_irqs[] = {
+ { .irq = INT_34XX_L3_DBG_IRQ },
+ { .irq = INT_34XX_L3_APP_IRQ },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_l3_targ_addrs[] = {
+ {
+ .pa_start = 0x6800,
+ .pa_end = 0x6810,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
/* MPU - L3 interface */
static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
- .master = omap3xxx_mpu_hwmod,
- .slave = omap3xxx_l3_main_hwmod,
+ .master = omap3xxx_mpu_hwmod,
+ .slave= omap3xxx_l3_main_hwmod,
+ .addr = omap3xxx_l3_targ_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_l3_targ_addrs),
.user = OCP_USER_MPU,
};
@@ -94,6 +110,8 @@ static struct omap_hwmod_ocp_if
*omap3xxx_l3_main_masters[] = {
static struct omap_hwmod omap3xxx_l3_main_hwmod = {
.name = l3_main,
.class = l3_hwmod_class,
+ .mpu_irqs = omap3xxx_l3_targ_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_l3_targ_irqs),
.masters= omap3xxx_l3_main_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_main_masters),
.slaves = omap3xxx_l3_main_slaves,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 2910de9..e614de1 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -315,6 +315,8 @@
#define INT_34XX_SSM_ABORT_IRQ 6
#define INT_34XX_SYS_NIRQ 7
#define INT_34XX_D2D_FW_IRQ8
+#define INT_34XX_L3_DBG_IRQ 9
+#define INT_34XX_L3_APP_IRQ 10
#define INT_34XX_PRCM_MPU_IRQ 11
#define INT_34XX_MCBSP1_IRQ16
#define INT_34XX_MCBSP2_IRQ17
--
1.7.0.4
Thanks,
Sricharan
--
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
RE: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod database.
Hi Benoit,
-Original Message-
From: Sricharan R [mailto:r.sricha...@ti.com]
Sent: Wednesday, February 23, 2011 11:09 AM
To: Benoit Cousson; Santosh Shilimkar
Cc: 'linux-omap@vger.kernel.org'; Felipe Balbi
Subject: RE: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to hwmod
database.
Hi Benoit,
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Monday, February 21, 2011 8:10 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; Balbi, Felipe; R, Sricharan
Subject: Re: [PATCH 4/6] omap4: hwmod_data: Add l3 errorlog data to
hwmod
database.
Hi Sricharan,
On 2/21/2011 2:46 PM, Shilimkar, Santosh wrote:
From: sricharanr.sricha...@ti.com
Add the error log registers, irqs of the l3 interconnect to the
hwmod data. The hwmod change is aligned with Benoit Cousson.
Hi Benoit,
The change is almost aligned with Benoit Cousson :-)
The subject should be something like: omap4: hwmod data: Add address
space and irq in L3 hwmod
There is no errolog data in that patch. The changelog should be updated
too.
Ok. I will change the subject and the change log as well.
Here is the updated patch as per your suggestions.
-
[PATCH v2 4/6] omap4: hwmod_data: Add address space and irq in L3 hwmod.
Add the address spaces, irqs of the l3 interconnect to the
hwmod data. The hwmod change is aligned with Benoit Cousson.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: sricharan r.sricha...@ti.com
Tested-by: sricharan r.sricha...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
changed the subject line and the changelog
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..95001d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -229,11 +229,37 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L3 target configuration and error log registers */
+static struct omap_hwmod_irq_info omap44xx_l3_targ_irqs[] = {
+ { .irq = 9 + OMAP44XX_IRQ_GIC_START },
+ { .irq = 10 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_l3_targ_addrs[] = {
+ {
+ .pa_start = 0x4400,
+ .pa_end = 0x4410,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ .pa_start = 0x4480,
+ .pa_end = 0x4490,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ .pa_start = 0x4500,
+ .pa_end = 0x4510,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
/* mpu - l3_main_1 */
static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 = {
.master = omap44xx_mpu_hwmod,
.slave = omap44xx_l3_main_1_hwmod,
.clk= l3_div_ck,
+ .addr = omap44xx_l3_targ_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_l3_targ_addrs),
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -248,6 +274,8 @@ static struct omap_hwmod_ocp_if
*omap44xx_l3_main_1_slaves[] = {
static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
.name = l3_main_1,
.class = omap44xx_l3_hwmod_class,
+ .mpu_irqs = omap44xx_l3_targ_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_targ_irqs),
.slaves = omap44xx_l3_main_1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_1_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
--
1.7.0.4
--
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
RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
Hi paul, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Santosh Shilimkar Sent: Monday, January 17, 2011 10:09 PM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 06, 2011 11:56 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM Hi Santosh, On Wed, 5 Jan 2011, Santosh Shilimkar wrote: Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism' introduced watchdog timer state state management using postsetup_state. This was done to allow some board files to support watchdog coverage throughout kernel initialization and it work as intended when RUNTIME_PM is enabled. With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog to remain enabled the omap_wdt_probe crashesh. This is because hwmod in absense of runtime PM unable to turn watchdog clocks because it's state is set to be disabled. For rest of the device, the state is set as enabled in absense of RUNTIME_PM [1.372558] Unhandled fault: imprecise external abort (0x1406) at 0xad733eeb [1.379913] Internal error: : 1406 [#1] SMP [1.384277] last sysfs file: [1.387359] Modules linked in: [1.390563] CPU: 0Tainted: GW(2.6.37-rc7-00265- g4298a4c-dirty #23) [1.398468] PC is at omap_wdt_disable+0x2c/0x3c [1.403198] LR is at omap_wdt_probe+0x124/0x1e0 [1.407928] pc : [c02f5bf4]lr : [c03be10c]psr: 6013 [1.407958] sp : df833f00 ip : fp : [1.419921] r10: c0ac57ac r9 : df959e00 r8 : [1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0 [1.432189] r3 : fc314000 r2 : r1 : fc314034 r0 : df87dde0 This patch make the default watchdog state to be enabled in case of !CONFIG_RUNTIME_PM. This fixes the crash Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Paul, I am not too sure if it breaks your _shutdown idea of watchdog timer. Maybe. What happens in a case where the bootloader enables the watchdog, but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly in that case? Or am I missing something... I tried this scenario and some how the WDT isn't reseting MPU with my patch. Actually I was expecting it should reset but it didn't. Regards, Santosh In the case of !CONFIG_PM_RUNTIME and !CONFIG_OMAP_WATCHDOG, if the boot loader or hwmod enables the watchdog, then it generates an un wanted reset. So to avoid this in the case of !CONFIG_OMAP_WATCHDOG then the watchdog should always be disabled. So there are two cases: Case 1: (!CONFIG_OMAP_WATCHDOG and !CONFIG_PM_RUNTIME) Watchdog should be disabled. Case 2: (!CONFIG_PM_RUNTIME) and ( driver is present and board file enables it) Watchdog should run. Solution1: Introduce a new hwmod watchdog reset function, by populating the .reset entry of the hwmod. This function is called during the hwmod init. This function resets the watchdog always and also disables it if !CONFIG_OMAP_WATCHDOG. ( or ) Solution2: Introduce a state variable to differentiate if hwmod post_setup_state is set to enabled by by board file or io.c file. Use this state variable in the reset function as If it is enabled by io.c then disable watchdog Otherwise if it is set to enabled by board file then enable watchdog. The below is the patch for solution1, that I have mentioned. Please suggest which would be the right approach ? diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 657f3c8..2641d73 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -382,24 +382,6 @@ void __init omap2_init_common_infrastructure(void) #endif omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state); - /* -* Set the default postsetup state for unusual modules (like -* MPU WDT). -* -* The postsetup_state is not actually used until -* omap_hwmod_late_init(), so boards that desire full watchdog -* coverage of kernel initialization can reprogram the -* postsetup_state between the calls to -* omap2_init_common_infra() and omap2_init_common_devices(). -* -* XXX ideally we could detect whether the MPU WDT was currently -* enabled here and make this conditional -*/ -
RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic.
Hi Tony,
From: Tony Lindgren t...@atomide.com
Date: Tue, 22 Feb 2011 16:05:15 -0800
Subject: [PATCH] omap2+: Add separate list for dynamic pads to mux
This avoids going through the list unnecessarily when
idling devices for runtime PM.
Based on an earlier patch by sricharan r.sricha...@ti.com.
yes, this looks simpler actually.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -258,7 +258,7 @@ struct omap_hwmod_mux_info * __init
omap_hwmod_mux_init(struct omap_device_pad *bpads, int nr_pads)
{
struct omap_hwmod_mux_info *hmux;
- int i;
+ int i, nr_pads_dynamic = 0;
if (!bpads || nr_pads 1)
return NULL;
@@ -302,9 +302,40 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads,
int
nr_pads)
pad-enable = bpad-enable;
pad-idle = bpad-idle;
pad-off = bpad-off;
+
+ if (pad-flags OMAP_DEVICE_PAD_REMUX)
+ nr_pads_dynamic++;
+
pr_debug(%s: Initialized %s\n, __func__, pad-name);
}
+ if (!nr_pads_dynamic)
+ return hmux;
+
+ /*
+ * Add pads that need dynamic muxing into a separate list
+ */
+
+ hmux-nr_pads_dynamic = nr_pads_dynamic;
+ hmux-pads_dynamic = kzalloc(sizeof(struct omap_device_pad *) *
+ nr_pads_dynamic, GFP_KERNEL);
+ if (!hmux-pads_dynamic) {
+ pr_err(%s: Could not allocate dynamic pads\n, __func__);
+ return hmux;
+ }
+
+ nr_pads_dynamic = 0;
+ for (i = 0; i hmux-nr_pads; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+
+ if (pad-flags OMAP_DEVICE_PAD_REMUX) {
+ pr_debug(%s: pad %s tagged dynamic\n,
+ __func__, pad-name);
+ hmux-pads_dynamic[nr_pads_dynamic] = pad;
+ nr_pads_dynamic++;
+ }
+ }
+
return hmux;
err3:
@@ -322,6 +353,46 @@ void omap_hwmod_mux(struct omap_hwmod_mux_info
*hmux,
u8 state)
{
int i;
+ /* Runtime idling of dynamic pads */
+ if (state == _HWMOD_STATE_IDLE hmux-enabled) {
+ for (i = 0; i hmux-nr_pads_dynamic; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+ int val = -EINVAL;
+
+ pad-flags = ~OMAP_DEVICE_PAD_ENABLED;
+ pad-flags |= OMAP_DEVICE_PAD_IDLE;
+ val = pad-idle;
+ omap_mux_write(pad-partition, val,
+ pad-mux-reg_offset);
+ }
+
+ return;
+ }
+
+ /* Runtime enabling of dynamic pads */
+ if ((state == _HWMOD_STATE_ENABLED) hmux-pads_dynamic) {
+ int idled = 0;
+
+ for (i = 0; i hmux-nr_pads_dynamic; i++) {
+ struct omap_device_pad *pad = hmux-pads[i];
+ int val = -EINVAL;
+
+ if (!(pad-flags OMAP_DEVICE_PAD_IDLE))
+ continue;
+
+ pad-flags = ~OMAP_DEVICE_PAD_IDLE;
+ pad-flags |= OMAP_DEVICE_PAD_ENABLED;
+ val = pad-enable;
+ omap_mux_write(pad-partition, val,
+ pad-mux-reg_offset);
+ idled++;
+ }
+
+ if (idled)
+ return;
+ }
+
+ /* Enabling, disabling or idling of all pads */
for (i = 0; i hmux-nr_pads; i++) {
struct omap_device_pad *pad = hmux-pads[i];
int flags, val = -EINVAL;
@@ -363,6 +434,11 @@ void omap_hwmod_mux(struct omap_hwmod_mux_info
*hmux,
u8 state)
pad-flags = flags;
}
}
+
+ if (state == _HWMOD_STATE_ENABLED)
+ hmux-enabled = true;
+ else
+ hmux-enabled = false;
}
#ifdef CONFIG_DEBUG_FS
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -159,7 +159,8 @@ struct omap_board_mux {
u16 value;
};
-#define OMAP_DEVICE_PAD_ENABLED BIT(7) /* Not needed for
board-*.c */
+#define OMAP_DEVICE_PAD_IDLE BIT(7) /* Not needed for
board-*.c
*/
+#define OMAP_DEVICE_PAD_ENABLED BIT(6) /* Not needed for
board-*.c */
#define OMAP_DEVICE_PAD_REMUX BIT(1) /* Dynamically remux
a pad,
needs enable, idle and
off
values */
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1230,8 +1230,9 @@ static int _enable(struct omap_hwmod *oh)
_deassert_hardreset(oh, oh-rst_lines[0].name);
/* Mux pins for device runtime if populated */
- if (oh-mux)
- omap_hwmod_mux(oh-mux,
RE: [PATCH 2/5] omap4: board-4430sdp: Initialise the serial pads
Hi Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, February 24, 2011 12:20 AM
To: sricharan
Cc: linux-omap@vger.kernel.org; santosh.shilim...@ti.com; p...@pwsan.com
Subject: Re: [PATCH 2/5] omap4: board-4430sdp: Initialise the serial pads
* sricharan r.sricha...@ti.com [110127 21:04]:
Use the mux framework to initialise the serial pads.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 73
++-
1 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 1cb208b..d77f099 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -537,8 +537,79 @@ static void __init omap_sfh7741prox_init(void)
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+{ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .flags = OMAP_DEVICE_PAD_REMUX_IDLE,
+ .idle = OMAP_MUX_MODE7,
+},
Is there need to dynamically remux uart2_cts? If so, please
describe the reason in the patch description and comments.
Note that if there's need for dynamic remuxing, this should
be updated for just OMAP_DEVICE_PAD_REMUX to work with the
patch I posted to replace patch 1/5.
Actually there was not a need for remixing here. I added
This for testing purpose.i will remove this and send a updated
Patch.
Regards,
Tony
--
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
RE: [PATCH 5/5] omap2+: board-n8x0: Change the flags for the serial pads.
Hi Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, February 24, 2011 12:20 AM
To: sricharan
Cc: linux-omap@vger.kernel.org; santosh.shilim...@ti.com; p...@pwsan.com
Subject: Re: [PATCH 5/5] omap2+: board-n8x0: Change the flags for the
serial pads.
* sricharan r.sricha...@ti.com [110127 21:05]:
The flag for remuxing uart3_rx_irxx pad is changed.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-n8x0.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-
omap2/board-n8x0.c
index 9b52e2d..bd51356 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -751,7 +751,7 @@ static struct omap_board_mux board_mux[] __initdata
=
{
static struct omap_device_pad serial2_pads[] __initdata = {
{
.name = uart3_rx_irrx.uart3_rx_irrx,
-.flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+.flags = OMAP_DEVICE_PAD_REMUX_IDLE |
OMAP_DEVICE_PAD_WAKEUP,
.enable = OMAP_MUX_MODE0,
.idle = OMAP_MUX_MODE3/* Mux as GPIO for idle */
},
This should not be needed when rebased on my patch to replace patch 1/5.
Yes correct. This patch should not be needed now.
Regards,
Tony
--
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
RE: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial pads
Hi Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, February 24, 2011 12:20 AM
To: sricharan
Cc: linux-omap@vger.kernel.org; santosh.shilim...@ti.com; p...@pwsan.com
Subject: Re: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial
pads
* sricharan r.sricha...@ti.com [110127 21:05]:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,83 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+{ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .flags = OMAP_DEVICE_PAD_REMUX_IDLE,
+ .idle = OMAP_MUX_MODE7,
+},
Here too please check the need for dynamic remuxing and
update the patch if necessary.
Actually there was not a need for remixing here. I added
This for testing purpose.i will remove this and send an updated
Patch.
Regards,
Tony
--
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
RE: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
Hi,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 755f4aa..530e9e3 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,15 @@
static int omap_uart_con_id __initdata = -1;
+static struct omap_uart_port_info omap_serial_default_info[] = {
+ {
+ .dma_enabled= 0,
+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+ .idle_timeout = DEFAULT_IDLE_TIMEOUT,
+ },
+};
+
static int uart_idle_hwmod(struct omap_device *od)
{
omap_hwmod_idle(od-hwmods[0]);
@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
= {
},
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_serial0_pads[] __initdata = {
+ {
+ .name = uart1_rx.uart1_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_serial1_pads[] __initdata = {
+ {
+ .name = uart2_rx.uart2_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_serial2_pads[] __initdata = {
+ {
+ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad default_omap36xx_serial3_pads[] __initdata
=
{
+ {
+ .name = gpmc_wait3.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE2,
+ },
+};
+
+static struct omap_device_pad default_omap4_serial3_pads[] __initdata =
{
+ {
+ .name = uart4_rx.uart4_rx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ },
+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx pins?
Is it consistent that across all socs that only UART3 would have UART/IRDA
functions capability so that serial2 pads can always be called rx_irxx
?.
Thanks,
sricharan
--
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
--
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
RE: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
Hi,
-Original Message-
From: Govindraj [mailto:govindraj...@gmail.com]
Sent: Wednesday, March 02, 2011 1:11 PM
To: Sricharan R
Cc: Govindraj.R; linux-omap@vger.kernel.org;
linux-ser...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
configured from board file
On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R r.sricha...@ti.com wrote:
Hi,
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 755f4aa..530e9e3 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,15 @@
static int omap_uart_con_id __initdata = -1;
+static struct omap_uart_port_info omap_serial_default_info[] = {
+ Â Â Â {
+        .dma_enabled   = 0,
+ Â Â Â Â Â Â Â .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ Â Â Â Â Â Â Â .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+        .idle_timeout  = DEFAULT_IDLE_TIMEOUT,
+ Â Â Â },
+};
+
static int uart_idle_hwmod(struct omap_device *od)
{
   omap_hwmod_idle(od-hwmods[0]);
@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
= {
   },
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_serial0_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart1_rx.uart1_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_serial1_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart2_rx.uart2_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_serial2_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart3_rx_irrx.uart3_rx_irrx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_omap36xx_serial3_pads[]
__initdata
=
{
+ Â Â Â {
+        .name  = gpmc_wait3.uart4_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE2,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_omap4_serial3_pads[] __initdata
=
{
+ Â Â Â {
+        .name  = uart4_rx.uart4_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx
pins?
The intention here is to enable wakeup capabilities for uart rx pad.
AFAIK most of the boards are currently dependent on bootloader for
uart-muxing if any board is not dependent on bootloader then we
can use omap_serial_init_port along with board_mux_info from board.
Yes. The idea is to be independent of the bootloaders for mux settings.
Prior to this change uart wakeup is based on rx_pad and we were
populating
offset and using omap_ctrl api's to read/write which is cleaned up now.
Most of boards are dependent on uart-rx wakeup to avoid breaking any
board support we
are using omap_serial_init by filling default values, which provides
us with same
environment but with right approach towards handling mux data with a
handshake with
hwmod framework.
Now, in this change only the RX pin is configured. So if some board uses
omap_serial_init then only the RX is going to be configured.
How will they configure the rest of the pins?
They cannot call omap_serial_init_port after this just to configure the
rest of the mux pins( cts, rts, tx).
So data which is passed from omap_serial_init should have the
configuration
for all the pins, and this default data should be consistent across
atleast
some boards, so that they can use this. This will reduce the data
duplication across board files.
If this is not true, then all the pads can be configured from the board
files itself using omap_serial_init_port and you can set the required
RX wakeup capability there as well.
So if any board needs specific mux they can go ahead and add required
mux data in
board file and use map_serial_init_port instead of current
omap_serial_init.
Is it consistent that across all socs that only UART3 would have
UART/IRDA
functions capability so that serial2 pads can always be called
rx_irxx
?.
Yes from OMAP2420 to OMAP4430 uart3 can used as irda.
Ok.
--
Thanks,
Govindraj.R
--
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
RE: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
Hi,
-Original Message-
From: Govindraj [mailto:govindraj...@gmail.com]
Sent: Wednesday, March 02, 2011 3:37 PM
To: Sricharan R
Cc: Govindraj.R; linux-omap@vger.kernel.org;
linux-ser...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
configured from board file
On Wed, Mar 2, 2011 at 1:49 PM, Sricharan R r.sricha...@ti.com wrote:
Hi,
-Original Message-
From: Govindraj [mailto:govindraj...@gmail.com]
Sent: Wednesday, March 02, 2011 1:11 PM
To: Sricharan R
Cc: Govindraj.R; linux-omap@vger.kernel.org;
linux-ser...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Jon Hunter; Tony Lindgren; Benoit
Cousson; Kevin Hilman; Paul Walmsley; Rajendra Nayak; Deepak Kattungal
Subject: Re: [PATCH 6/7] OMAP: Serial: Allow UART parameters to be
configured from board file
On Wed, Mar 2, 2011 at 12:46 AM, Sricharan R r.sricha...@ti.com
wrote:
Hi,
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index 755f4aa..530e9e3 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,15 @@
static int omap_uart_con_id __initdata = -1;
+static struct omap_uart_port_info omap_serial_default_info[] = {
+ Â Â Â {
+        .dma_enabled   = 0,
+ Â Â Â Â Â Â Â .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
+ Â Â Â Â Â Â Â .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
+        .idle_timeout  = DEFAULT_IDLE_TIMEOUT,
+ Â Â Â },
+};
+
static int uart_idle_hwmod(struct omap_device *od)
{
   omap_hwmod_idle(od-hwmods[0]);
@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
= {
   },
};
+#ifdef CONFIG_OMAP_MUX
+static struct omap_device_pad default_serial0_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart1_rx.uart1_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_serial1_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart2_rx.uart2_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_serial2_pads[] __initdata = {
+ Â Â Â {
+        .name  = uart3_rx_irrx.uart3_rx_irrx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_omap36xx_serial3_pads[]
__initdata
=
{
+ Â Â Â {
+        .name  = gpmc_wait3.uart4_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE2,
+ Â Â Â },
+};
+
+static struct omap_device_pad default_omap4_serial3_pads[]
__initdata
=
{
+ Â Â Â {
+        .name  = uart4_rx.uart4_rx,
+        .flags  = OMAP_DEVICE_PAD_REMUX |
OMAP_DEVICE_PAD_WAKEUP,
+ Â Â Â Â Â Â Â .enable = OMAP_MUX_MODE0,
+ Â Â Â },
+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx
pins?
The intention here is to enable wakeup capabilities for uart rx pad.
AFAIK most of the boards are currently dependent on bootloader for
uart-muxing if any board is not dependent on bootloader then we
can use omap_serial_init_port along with board_mux_info from board.
Yes. The idea is to be independent of the bootloaders for mux settings.
Prior to this change uart wakeup is based on rx_pad and we were
populating
offset and using omap_ctrl api's to read/write which is cleaned up now.
Most of boards are dependent on uart-rx wakeup to avoid breaking any
board support we
are using omap_serial_init by filling default values, which provides
us with same
environment but with right approach towards handling mux data with a
handshake with
hwmod framework.
Now, in this change only the RX pin is configured. So if some board
uses
omap_serial_init then only the RX is going to be configured.
How will they configure the rest of the pins?
They should call omap_serial_init_port to configure each individual uart
with
mux_info filled and not use omap_serial_init.
If any board is not dependent for mux from u-boot then they use above
said
init_port func.
They cannot call omap_serial_init_port after this just to configure the
rest of the mux pins( cts, rts, tx).
No. You need to use either omap_serial_init_port or omap_serial_init
you cannot call both apis from board file please refer to both func
documentation.
Also please note i am not configuring all uart pins for pullups and pull
downs
with this patch series and its not related to this patch series.
I am only enabling wakeup-enable pin for rx as it was done before.
So data which is passed from omap_serial_init should have the
configuration
for all the pins, and this default data should be consistent across
atleast
some boards, so that they can use
RE: [PATCH] omap2+: mux: Initialise the static pads.
Hi Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, March 04, 2011 11:13 PM
To: Sricharan R
Cc: linux-omap@vger.kernel.org; Benoit Cousson; p...@pswan.com; Santosh
Shilimkar
Subject: Re: [PATCH] omap2+: mux: Initialise the static pads.
* Sricharan R r.sricha...@ti.com [110304 09:31]:
Hi Tony,
Hmm it's there as commit 93c5f165e10c21a3813a687204388a34072b2a62
in devel-mux branch. Can you please update your patch against
that commit so it's easier to see what your changes are?
BTW, the patch you posted got trashed by your email client
or server..
Here is the updated patch on top of your previous patch.
The patch formatting is still trashed, notice the double line
spacing..
Very sorry about this.
Below is the link for the patch.
http://marc.info/?l=linux-omapm=129947252016935w=2
+++ b/arch/arm/mach-omap2/mux.c
@@ -359,7 +359,6 @@ void omap_hwmod_mux(struct omap_hwmod_mux_info
*hmux,
u8
state)
..and the line wrapping of the patch lines.
+ if ((state == _HWMOD_STATE_ENABLED) hmux-pads_dynamic
+ hmux-enabled) {
Yes I see that might allow removing the idle flag. Will give it
a try with my testcase once you get your mail issue sorted out
and can post a patch that applies.
Ok. I have checked this applies on top of the devel-mux branch.
Tony
Thanks,
Sricharan
--
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
RE: [PATCH] omap2+: mux: Remove the use of IDLE flag.
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, March 08, 2011 10:11 PM To: sricharan Cc: linux-omap@vger.kernel.org; b-cous...@ti.com; santosh.shilim...@ti.com; p...@pswan.com Subject: Re: [PATCH] omap2+: mux: Remove the use of IDLE flag. * sricharan r.sricha...@ti.com [110306 20:33]: Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins dynamically. This can be simplified by using the enabled state variable of each pad. This also fixes the issue of the static pads not getting muxed after idling and disable/enable state transitions. Looks good, can you please repost one more time with linux-arm-kernel mailing list also Cc'd? Ok sure. I have re posted this to the linux-arm-kernel list. Thanks, Tony -- 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 -- 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
RE: [PATCH] omap2+: mux: Remove the use of IDLE flag.
Tony, -Original Message- From: Sricharan R [mailto:r.sricha...@ti.com] Sent: Wednesday, March 09, 2011 1:19 PM To: 'Tony Lindgren' Cc: 'linux-omap@vger.kernel.org'; Benoit Cousson; Santosh Shilimkar; 'p...@pswan.com'; 'linux-arm-ker...@lists.infradead.org' Subject: RE: [PATCH] omap2+: mux: Remove the use of IDLE flag. [] * sricharan r.sricha...@ti.com [110306 20:33]: Currently OMAP_DEVICE_PAD_IDLE flag is used to mux pins dynamically. This can be simplified by using the enabled state variable of each pad. This also fixes the issue of the static pads not getting muxed after idling and disable/enable state transitions. Looks good, can you please repost one more time with linux-arm-kernel mailing list also Cc'd? Ok sure. I have re posted this to the linux-arm-kernel list. Btw,I have fixed the comments on the below patches that I sent for configuring the serial pads. 4430sdp: http://marc.info/?l=linux-omapm=129900334420003w=2 omap4panda: http://marc.info/?l=linux-omapm=129900338520082w=2 3430sdp: http://marc.info/?l=linux-omapm=129619117726479w=2 Can you please check if they are ok? Thanks, Sricharan -- 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
RE: [PATCH] omap2+: mux: Add macro for configuring static with omap_hwmod_mux_init (Re: [PATCH] omap2+: mux: Remove the use of IDLE flag)
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, March 10, 2011 2:02 AM
To: Sricharan R
Cc: linux-omap@vger.kernel.org; Benoit Cousson; Santosh Shilimkar;
p...@pswan.com; linux-arm-ker...@lists.infradead.org
Subject: [PATCH] omap2+: mux: Add macro for configuring static with
omap_hwmod_mux_init (Re: [PATCH] omap2+: mux: Remove the use of IDLE
flag)
* Sricharan R r.sricha...@ti.com [110309 03:47]:
Btw,I have fixed the comments on the below patches that
I sent for configuring the serial pads.
4430sdp:
http://marc.info/?l=linux-omapm=129900334420003w=2
omap4panda:
http://marc.info/?l=linux-omapm=129900338520082w=2
3430sdp:
http://marc.info/?l=linux-omapm=129619117726479w=2
Can you please check if they are ok?
Look OK to me, but let's make things a bit easier to read
and maintain with the following patch. Can you please
update your patches to use this macro?
Each line then just becomes something like:
OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx,
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
Ok thanks. I will update and send again.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 9 Mar 2011 12:14:04 -0800
Subject: [PATCH] omap2+: mux: Add macro for configuring static with
omap_hwmod_mux_init
Add macro for defining static pins in the board file.
We can now start implementing pin multiplexing in the platform init
code for devices that call omap_hwmod_mux_init. Currently that is
only implemented for serial.c.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -186,6 +186,12 @@ struct omap_device_pad {
struct omap_hwmod_mux_info;
+#define OMAP_MUX_STATIC(signal, mode) \
+{ \
+ .name = (signal), \
+ .enable = (mode), \
+}
+
#if defined(CONFIG_OMAP_MUX)
/**
--
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
RE: [PATCH] omap2+: mux: Add macro for configuring static with omap_hwmod_mux_init (Re: [PATCH] omap2+: mux: Remove the use of IDLE flag)
Tony, Look OK to me, but let's make things a bit easier to read and maintain with the following patch. Can you please update your patches to use this macro? Each line then just becomes something like: OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0), Ok thanks. I will update and send again. 4430SDP: http://marc.info/?l=linux-omapm=129982347622340w=2 omap4panda: http://marc.info/?l=linux-omapm=129982347722344w=2 3430sdp: http://marc.info/?l=linux-omapm=129982347822347w=2 I have reworked the patches using your MACRO. I have applied on top of the omap-for-linus branch and tested them on 4430sdp, 3430sdp, omap4panda. Thanks, Sricharan' -- 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
[PATCH] ARM: OMAP4: Enable fix for Cortex-A9 erratas
This enables the fixes for the below erratas applicable for OMAP4 Socs. 754322: Faulty MMU translations following ASID switch 775420: A data cache maintenance operation which aborts, followed by an ISB, without any DSB in-between, might lead to deadlock Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c3477e7..c4a3f3f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -73,6 +73,8 @@ config ARCH_OMAP4 select PM_RUNTIME if CPU_IDLE select USB_ARCH_HAS_EHCI if USB_SUPPORT select COMMON_CLK + select ARM_ERRATA_754322 + select ARM_ERRATA_775420 config SOC_OMAP5 bool TI OMAP5 -- 1.7.9.5 -- 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
[PATCH 0/4] ARM: dts: omap5: Cleanup and updates for DT files
uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Rename omap5-evm to omap5-uevm arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 --- arch/arm/boot/dts/omap5-uevm.dts | 319 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 350 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 1.7.9.5 -- 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
[PATCH 4/4] ARM: dts: omap5-uevm: Add uart pinctrl data
From: Sourav Poddar sourav.pod...@ti.com
Booting omap5 uevm results in the following error
did not get pins for uart error: -19
This happens because omap5 uevm dts file is not adapted to use uart through
pinctrl
framework. Populating uart pinctrl data to get rid of the error.
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a2aed5b..e545e64 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -192,6 +192,32 @@
0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 OUTPUT | MODE6 */
;
};
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x60 (PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_cts
MODE0 */
+ 0x62 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_tx.uart1_cts INPUT | PULLUP | MODE0 */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_rx.uart1_rts INPUT | PULLUP | MODE0 */
+ 0x66 (PIN_OUTPUT | MUX_MODE0) /* uart1_rx.uart1_rts
MODE0 */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x19a (PIN_OUTPUT | MUX_MODE0) /*
uart3_rts_irsd.uart3_tx_irtx MODE0 */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart3_rx_irrx.uart3_usbb3_hsic INPUT | PULLUP | MODE0 */
+ ;
+ };
+
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_rx.uart5_rx INPUT | PULLUP | MODE0 */
+ 0x172 (PIN_OUTPUT | MUX_MODE0) /* uart5_tx.uart5_tx
MODE0 */
+ 0x174 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_cts.uart5_rts INPUT | PULLUP | MODE0 */
+ 0x176 (PIN_OUTPUT | MUX_MODE0) /* uart5_cts.uart5_rts
MODE0 */
+ ;
+ };
+
};
omap5_pmx_wkup {
@@ -276,3 +302,18 @@
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
};
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart3 {
+pinctrl-names = default;
+pinctrl-0 = uart3_pins;
+};
+
+uart5 {
+pinctrl-names = default;
+pinctrl-0 = uart5_pins;
+};
--
1.7.9.5
--
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
[PATCH 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index cf862df..a2aed5b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -66,6 +66,16 @@
device = hsusb2_phy;
clock-frequency = 1920; /* 19.2 MHz */
};
+
+ leds {
+ compatible = gpio-leds;
+ led@1 {
+ label = omap5:blue:usr1;
+ gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1
LED */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
omap5_pmx_core {
@@ -77,6 +87,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+ led_gpio_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -175,6 +186,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 OUTPUT | MODE
6 ETH_NRESET */
;
};
+
+ led_gpio_pins: pinmux_led_gpio_pins {
+ pinctrl-single,pins =
+ 0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 OUTPUT | MODE6 */
+ ;
+ };
};
omap5_pmx_wkup {
--
1.7.9.5
--
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
[PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 77 ++
arch/arm/boot/dts/omap5.dtsi | 30 +++
2 files changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,47 @@
regulator-max-microvolt = 300;
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ };
+
+ /* HS USB Port 3 RESET */
+ hsusb3_reset: hsusb3_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb3_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 3 */
+ hsusb3_phy: hsusb3_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb3_reset;
+ };
+
+ /* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+ clock_alias {
+ clock-name = auxclk1_ck;
+ clock-alias = main_clk;
+ device = hsusb2_phy;
+ clock-frequency = 1920; /* 19.2 MHz */
+ };
};
omap5_pmx_core {
@@ -35,6 +76,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+ usbhost_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +162,32 @@
0x16c (PIN_INPUT | MUX_MODE1) /* mcspi2_cs */
;
};
+
+ usbhost_pins: pinmux_usbhost_pins {
+ pinctrl-single,pins =
+ 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe INPUT
| MODE 0 */
+ 0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data INPUT |
MODE 0 */
+
+ 0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe
INPUT | MODE 0 */
+ 0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data INPUT
| MODE 0 */
+
+ 0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 OUTPUT | MODE
6 HUB_NRESET */
+ 0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 OUTPUT | MODE
6 ETH_NRESET */
+ ;
+ };
+};
+
+omap5_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ usbhost_wkup_pins
+ ;
+
+ usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+ pinctrl-single,pins =
+ 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out OUTPUT |
MODE 7 for USB hub clk */
+ ;
+ };
};
mmc1 {
@@ -164,6 +232,15 @@
status = disabled;
};
+usbhshost {
+ port2-mode = ehci-hsic;
+ port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy hsusb3_phy;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..67d6e1f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = 0 78 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci
[PATCH 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
arch/arm/boot/dts/omap5-evm.dts | 261 --
arch/arm/boot/dts/omap5-uevm.dts | 184 +++
3 files changed, 185 insertions(+), 262 deletions(-)
delete mode 100644 arch/arm/boot/dts/omap5-evm.dts
create mode 100644 arch/arm/boot/dts/omap5-uevm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
deleted file mode 100644
index 22e9ee8..000
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ /dev/null
@@ -1,261 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-/dts-v1/;
-
-#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
-
-/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
-
- memory {
- device_type = memory;
- reg = 0x8000 0x7F00; /* 2032 MB */
- };
-
- vmmcsd_fixed: fixedregulator-mmcsd {
- compatible = regulator-fixed;
- regulator-name = vmmcsd_fixed;
- regulator-min-microvolt = 300;
- regulator-max-microvolt = 300;
- };
-
-};
-
-omap5_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- twl6040_pins
- mcpdm_pins
- dmic_pins
- mcbsp1_pins
- mcbsp2_pins
- ;
-
- twl6040_pins: pinmux_twl6040_pins {
- pinctrl-single,pins =
- 0x18a (PIN_OUTPUT | MUX_MODE6) /*
perslimbus2_clock.gpio5_145 */
- ;
- };
-
- mcpdm_pins: pinmux_mcpdm_pins {
- pinctrl-single,pins =
- 0x142 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abe_clks.abe_clks */
- 0x15c (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_ul_data.abemcpdm_ul_data */
- 0x15e (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_dl_data.abemcpdm_dl_data */
- 0x160 (PIN_INPUT_PULLUP | MUX_MODE0)/*
abemcpdm_frame.abemcpdm_frame */
- 0x162 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_lb_clk.abemcpdm_lb_clk */
- ;
- };
-
- dmic_pins: pinmux_dmic_pins {
- pinctrl-single,pins =
- 0x144 (PIN_INPUT | MUX_MODE0) /*
abedmic_din1.abedmic_din1 */
- 0x146 (PIN_INPUT | MUX_MODE0) /*
abedmic_din2.abedmic_din2 */
- 0x148 (PIN_INPUT | MUX_MODE0) /*
abedmic_din3.abedmic_din3 */
- 0x14a (PIN_OUTPUT | MUX_MODE0) /*
abedmic_clk1.abedmic_clk1 */
- ;
- };
-
- mcbsp1_pins: pinmux_mcbsp1_pins {
- pinctrl-single,pins =
- 0x14c (PIN_INPUT | MUX_MODE1) /*
abedmic_clk2.abemcbsp1_fsx */
- 0x14e (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
abedmic_clk3.abemcbsp1_dx */
- 0x150 (PIN_INPUT | MUX_MODE1) /*
abeslimbus1_clock.abemcbsp1_clkx */
- 0x152 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
abeslimbus1_data.abemcbsp1_dr */
- ;
- };
-
- mcbsp2_pins: pinmux_mcbsp2_pins {
- pinctrl-single,pins =
- 0x154 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcbsp2_dr.abemcbsp2_dr */
- 0x156 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
abemcbsp2_dx.abemcbsp2_dx */
- 0x158 (PIN_INPUT | MUX_MODE0) /*
abemcbsp2_fsx.abemcbsp2_fsx */
- 0x15a (PIN_INPUT | MUX_MODE0) /*
abemcbsp2_clkx.abemcbsp2_clkx */
- ;
- };
-
- i2c1_pins: pinmux_i2c1_pins
Re: [PATCH 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
On Wednesday 05 June 2013 12:16 PM, Sricharan R wrote:
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
arch/arm/boot/dts/omap5-evm.dts | 261
--
arch/arm/boot/dts/omap5-uevm.dts | 184 +++
3 files changed, 185 insertions(+), 262 deletions(-)
delete mode 100644 arch/arm/boot/dts/omap5-evm.dts
create mode 100644 arch/arm/boot/dts/omap5-uevm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
deleted file mode 100644
index 22e9ee8..000
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ /dev/null
@@ -1,261 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-/dts-v1/;
-
-#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
-
-/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
-
- memory {
- device_type = memory;
- reg = 0x8000 0x7F00; /* 2032 MB */
- };
-
- vmmcsd_fixed: fixedregulator-mmcsd {
- compatible = regulator-fixed;
- regulator-name = vmmcsd_fixed;
- regulator-min-microvolt = 300;
- regulator-max-microvolt = 300;
- };
-
-};
-
-omap5_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- twl6040_pins
- mcpdm_pins
- dmic_pins
- mcbsp1_pins
- mcbsp2_pins
- ;
-
- twl6040_pins: pinmux_twl6040_pins {
- pinctrl-single,pins =
- 0x18a (PIN_OUTPUT | MUX_MODE6) /*
perslimbus2_clock.gpio5_145 */
- ;
- };
-
- mcpdm_pins: pinmux_mcpdm_pins {
- pinctrl-single,pins =
- 0x142 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abe_clks.abe_clks */
- 0x15c (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_ul_data.abemcpdm_ul_data */
- 0x15e (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_dl_data.abemcpdm_dl_data */
- 0x160 (PIN_INPUT_PULLUP | MUX_MODE0)/*
abemcpdm_frame.abemcpdm_frame */
- 0x162 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcpdm_lb_clk.abemcpdm_lb_clk */
- ;
- };
-
- dmic_pins: pinmux_dmic_pins {
- pinctrl-single,pins =
- 0x144 (PIN_INPUT | MUX_MODE0) /*
abedmic_din1.abedmic_din1 */
- 0x146 (PIN_INPUT | MUX_MODE0) /*
abedmic_din2.abedmic_din2 */
- 0x148 (PIN_INPUT | MUX_MODE0) /*
abedmic_din3.abedmic_din3 */
- 0x14a (PIN_OUTPUT | MUX_MODE0) /*
abedmic_clk1.abedmic_clk1 */
- ;
- };
-
- mcbsp1_pins: pinmux_mcbsp1_pins {
- pinctrl-single,pins =
- 0x14c (PIN_INPUT | MUX_MODE1) /*
abedmic_clk2.abemcbsp1_fsx */
- 0x14e (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
abedmic_clk3.abemcbsp1_dx */
- 0x150 (PIN_INPUT | MUX_MODE1) /*
abeslimbus1_clock.abemcbsp1_clkx */
- 0x152 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
abeslimbus1_data.abemcbsp1_dr */
- ;
- };
-
- mcbsp2_pins: pinmux_mcbsp2_pins {
- pinctrl-single,pins =
- 0x154 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
abemcbsp2_dr.abemcbsp2_dr */
- 0x156 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
abemcbsp2_dx.abemcbsp2_dx */
- 0x158 (PIN_INPUT | MUX_MODE0) /*
abemcbsp2_fsx.abemcbsp2_fsx */
- 0x15a (PIN_INPUT | MUX_MODE0) /*
abemcbsp2_clkx.abemcbsp2_clkx
[PATCH 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83 +---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
mcspi1 {
};
--
1.7.9.5
--
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
Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
Hi,
On Wednesday 05 June 2013 01:29 PM, Florian Vaussard wrote:
Hello,
Some very minor comments.
On 06/05/2013 08:46 AM, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor
macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 77
++
arch/arm/boot/dts/omap5.dtsi | 30 +++
2 files changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,47 @@
regulator-max-microvolt = 300;
};
+/* HS USB Port 2 RESET */
+hsusb2_reset: hsusb2_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb2_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+startup-delay-us = 7;
+enable-active-high;
+};
+
+/* HS USB Host PHY on PORT 2 */
+hsusb2_phy: hsusb2_phy {
+compatible = usb-nop-xceiv;
+reset-supply = hsusb2_reset;
+};
+
+/* HS USB Port 3 RESET */
+hsusb3_reset: hsusb3_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb3_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+startup-delay-us = 7;
+enable-active-high;
+};
+
+/* HS USB Host PHY on PORT 3 */
+hsusb3_phy: hsusb3_phy {
+compatible = usb-nop-xceiv;
+reset-supply = hsusb3_reset;
+};
+
+/* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+clock_alias {
+clock-name = auxclk1_ck;
+clock-alias = main_clk;
+device = hsusb2_phy;
+clock-frequency = 1920; /* 19.2 MHz */
+};
};
omap5_pmx_core {
@@ -35,6 +76,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+usbhost_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +162,32 @@
0x16c (PIN_INPUT | MUX_MODE1)/* mcspi2_cs */
;
};
+
+usbhost_pins: pinmux_usbhost_pins {
+pinctrl-single,pins =
+0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe INPUT | MODE
0 */
+0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data INPUT | MODE 0
*/
Comments are redundant with the constants, so maybe you can leave this part
out.
Same for a few others below.
Ok, I agree here for attributes like pulls, i/o etc, comments are now not
required.
But comment is still good to describe just the mux mode functionality ?
One module will use different pins, like data, clk, gpios, etc. Just MUX_MODEX
does not
complete it..
+
+0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe INPUT | MODE
0 */
+0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data INPUT | MODE 0
*/
+
+0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 OUTPUT | MODE 6
HUB_NRESET */
+0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 OUTPUT | MODE 6
ETH_NRESET */
+;
+};
+};
+
+omap5_pmx_wkup {
+pinctrl-names = default;
+pinctrl-0 =
+usbhost_wkup_pins
+;
+
+usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+pinctrl-single,pins =
+0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out OUTPUT | MODE 7
for USB hub clk */
Mismatch between constants and comments, which mode should it be?
MODE 0. I see safe mode for 7. Comment should be corrected.
+;
+};
};
mmc1 {
@@ -164,6 +232,15 @@
status = disabled;
};
+usbhshost {
+port2-mode = ehci-hsic;
+port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+phys = 0 hsusb2_phy hsusb3_phy;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..67d6e1f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+usbhstll: usbhstll@4a062000 {
+compatible = ti,usbhs-tll;
+reg = 0x4a062000 0x1000;
+interrupts = 0 78 IRQ_TYPE_LEVEL_HIGH;
I guess that here you can replace '0' with GIC_SPI.
Thanks. Will replace here and below.
Regards,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
Hi Roger,
On Wednesday 05 June 2013 04:02 PM, Roger Quadros wrote:
Hi Sricharan,
Thanks for sending this, but some parts are outdated. See below.
On 06/05/2013 09:46 AM, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor
macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 77
++
arch/arm/boot/dts/omap5.dtsi | 30 +++
2 files changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,47 @@
regulator-max-microvolt = 300;
};
+/* HS USB Port 2 RESET */
+hsusb2_reset: hsusb2_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb2_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+startup-delay-us = 7;
+enable-active-high;
+};
+
+/* HS USB Host PHY on PORT 2 */
+hsusb2_phy: hsusb2_phy {
+compatible = usb-nop-xceiv;
+reset-supply = hsusb2_reset;
+};
+
+/* HS USB Port 3 RESET */
+hsusb3_reset: hsusb3_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb3_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+startup-delay-us = 7;
+enable-active-high;
+};
+
+/* HS USB Host PHY on PORT 3 */
+hsusb3_phy: hsusb3_phy {
+compatible = usb-nop-xceiv;
+reset-supply = hsusb3_reset;
+};
+
+/* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+clock_alias {
+clock-name = auxclk1_ck;
+clock-alias = main_clk;
+device = hsusb2_phy;
+clock-frequency = 1920; /* 19.2 MHz */
+};
clock_alias node is not required. Instead we need to rely on proper clock
binding
and provide reference to the clock phandle in the PHY node.
as an example please see here
https://lkml.org/lkml/2013/4/19/124
However this clock binding technique is still under discussion/transition.
https://patchwork.kernel.org/patch/2541331/
So, I suggest you leave the auxclk1 part out for now and we can get it in
later once
the clock binding stuff is sorted out. The side effect of this is that PORT 2
(i.e. USB Hub)
will not work. USB Ethernet should still work IMO.
Ok will drop that part then.
Thanks,
Sricharan
--
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
[PATCH V2 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Removed the redundant comments
arch/arm/boot/dts/omap5-uevm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a31e42f..6e8bb86 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -59,6 +59,15 @@
reset-supply = hsusb3_reset;
};
+ leds {
+ compatible = gpio-leds;
+ led@1 {
+ label = omap5:blue:usr1;
+ gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1
LED */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
omap5_pmx_core {
@@ -70,6 +79,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+ led_gpio_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -168,6 +178,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
;
};
+
+ led_gpio_pins: pinmux_led_gpio_pins {
+ pinctrl-single,pins =
+ 0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
+ ;
+ };
};
omap5_pmx_wkup {
--
1.7.9.5
--
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
[PATCH V2 4/4] ARM: dts: omap5-uevm: Add uart pinctrl data
From: Sourav Poddar sourav.pod...@ti.com
Booting omap5 uevm results in the following error
did not get pins for uart error: -19
This happens because omap5 uevm dts file is not adapted to use uart through
pinctrl
framework. Populating uart pinctrl data to get rid of the error.
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Removed the redundant comments
arch/arm/boot/dts/omap5-uevm.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6e8bb86..927db1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -184,6 +184,32 @@
0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
;
};
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x60 (PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_cts */
+ 0x62 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_tx.uart1_cts */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_rx.uart1_rts */
+ 0x66 (PIN_OUTPUT | MUX_MODE0) /* uart1_rx.uart1_rts */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x19a (PIN_OUTPUT | MUX_MODE0) /*
uart3_rts_irsd.uart3_tx_irtx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart3_rx_irrx.uart3_usbb3_hsic */
+ ;
+ };
+
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_rx.uart5_rx */
+ 0x172 (PIN_OUTPUT | MUX_MODE0) /* uart5_tx.uart5_tx */
+ 0x174 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_cts.uart5_rts */
+ 0x176 (PIN_OUTPUT | MUX_MODE0) /* uart5_cts.uart5_rts */
+ ;
+ };
+
};
omap5_pmx_wkup {
@@ -268,3 +294,18 @@
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
};
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart3 {
+pinctrl-names = default;
+pinctrl-0 = uart3_pins;
+};
+
+uart5 {
+pinctrl-names = default;
+pinctrl-0 = uart5_pins;
+};
--
1.7.9.5
--
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
[PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files
uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Rename omap5-evm to omap5-uevm arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 1.7.9.5 -- 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
[PATCH V2 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83 +---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
mcspi1 {
};
--
1.7.9.5
--
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
[PATCH V2 2/4] ARM: dts: omap5-uevm: Add USB Host support
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[v2] Removed the clk_alias node and removed the redundant comments
arch/arm/boot/dts/omap5-uevm.dts | 70 ++
arch/arm/boot/dts/omap5.dtsi | 30
2 files changed, 100 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..a31e42f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,40 @@
regulator-max-microvolt = 300;
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ };
+
+ /* HS USB Port 3 RESET */
+ hsusb3_reset: hsusb3_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb3_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 3 */
+ hsusb3_phy: hsusb3_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb3_reset;
+ };
+
};
omap5_pmx_core {
@@ -35,6 +69,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+ usbhost_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +155,32 @@
0x16c (PIN_INPUT | MUX_MODE1) /* mcspi2_cs */
;
};
+
+ usbhost_pins: pinmux_usbhost_pins {
+ pinctrl-single,pins =
+ 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
+ 0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data */
+
+ 0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe */
+ 0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data */
+
+ 0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 HUB_NRESET */
+ 0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
+ ;
+ };
+};
+
+omap5_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ usbhost_wkup_pins
+ ;
+
+ usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+ pinctrl-single,pins =
+ 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub
clk */
+ ;
+ };
};
mmc1 {
@@ -164,6 +225,15 @@
status = disabled;
};
+usbhshost {
+ port2-mode = ehci-hsic;
+ port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy hsusb3_phy;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..accab62 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible
Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
Hi,
On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
On 12:16-20130605, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
[...]
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
snip
+/* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+clock_alias {
+clock-name = auxclk1_ck;
+clock-alias = main_clk;
is'nt this better to use with clock node?
Roger was suggesting to remove this for now. Posted
V2 following that.
Are you suggesting to go with your clock-binding patch ?
Regards,
Sricharan
--
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
Re: [PATCH 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED
Hi,
On Wednesday 05 June 2013 10:34 PM, Dan Murphy wrote:
Sricharan
Thanks for sending this up in the series.
On 06/05/2013 01:46 AM, Sricharan R wrote:
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor
macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index cf862df..a2aed5b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -66,6 +66,16 @@
device = hsusb2_phy;
clock-frequency = 1920; /* 19.2 MHz */
};
+
+leds {
+compatible = gpio-leds;
+led@1 {
+label = omap5:blue:usr1;
+gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1
LED */
+linux,default-trigger = heartbeat;
+default-state = off;
+};
+};
};
omap5_pmx_core {
@@ -77,6 +87,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+led_gpio_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -175,6 +186,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 OUTPUT | MODE
6 ETH_NRESET */
;
};
+
+led_gpio_pins: pinmux_led_gpio_pins {
+pinctrl-single,pins =
+0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 OUTPUT | MODE6 */
Same comment from Florian. We can drop the OUTPUT | MODE6 in the comment.
Ok thanks, Corrected in V2.
Regards,
Sricharan
--
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
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 12:00 AM, Santosh Shilimkar wrote: On Thursday 06 June 2013 01:57 PM, Paul Walmsley wrote: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Sricharan R r.sricha...@ti.com - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnessecary hwmods like firewalls are removed as a part of this. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com I assume that you're not autogenerating this data any more, based on your change list above. If that's correct, please also remove the paragraph at the top of the file: The data is auto-generated. I let Sricharan comment if it is otherwise in the final version of the patch. Sricharan ? I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. Regards, Sricharan -- 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
Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support
On Friday 07 June 2013 12:16 AM, Nishanth Menon wrote:
On 23:21-20130606, Sricharan R wrote:
Hi,
On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
On 12:16-20130605, Sricharan R wrote:
From: Roger Quadros rog...@ti.com
[...]
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..cf862df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
snip
+ /* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
+ clock_alias {
+ clock-name = auxclk1_ck;
+ clock-alias = main_clk;
is'nt this better to use with clock node?
Roger was suggesting to remove this for now. Postedhen
V2 following that.
Are you suggesting to go with your clock-binding patch ?
you cannot. Mike has already rejected that approach and I have dropped
that series and wont be following up.
See discussion https://patchwork.kernel.org/patch/2541331/
instead the new approach being discussed
https://patchwork.kernel.org/patch/2657351/ and related discussions is
the way to go.
That said, it practically blocks introduction of all code that depend on
dts nodes :(, no matter how I dont like being blocked and my many series
delayed, I believe Mike, Tero, Rajendra are doing the right architecture
and we should wait for it's upstream introduction.
That is just my 2 cents.
Thanks for the details. So dropping the alias for now, should be fine.
Regards,
Sricharan
--
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
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. Regards, Sricharan -- 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
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On Friday 07 June 2013 03:20 PM, Paul Walmsley wrote: On Fri, 7 Jun 2013, Tero Kristo wrote: On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul + Ambresh and Tero for autogen. This is not going to happen soon, if ever. We might consider doing this if a complete overhaul for the hwmod data is going to be done at some point so that re-generating the new format is easier. OK. Sricharan, how about reposting the OMAP4 hwmod data patch and drop the comment regarding autogeneration? That will be more accurate and will save some more lines. - Paul ok, sure, i will repost by dropping that comment. Regards, Sricharan -- 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
Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Hi Benoit, On Friday 07 June 2013 04:13 PM, Benoit Cousson wrote: Hi Sricharan, On 06/07/2013 12:27 PM, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnessecary hwmods like firewalls are removed as a part of this. typo. Ok, will correct. That part is fine, but you should add that by doing that you have to create new direct link from MPU to EMIFs that did no exist before. Yes, the mpu-emif link is already added in the patch The above update, results in reduction of about ~1650 lines of code. The comment about autogeneration is removed temporarily. Should be brought back after syncing the scripts. You'd better keep it and append a note stating that. If you remove it, I fairly know nobody will ever add it again :-) Ok, will change this then :-) Otherwise the patch looks fine. Thanks, Benoit Regards, Sricharan -- 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
[PATCH V3 1/4] ARM: dts: omap5: Make uevm as the official board and deprecate sevm support
The uevm is the only official board supported for the OMAP5 soc
in mainline. The existent sevm platform will no more be supported.
Hence cleaning up the board dts file to have only the data
required for uevm.
Renaming the board dts file and adding the following cleanups.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* OMAP5432 and DDR3 memory is used in the uevm. Temperature polling
is not supported with DDR3 memories. Because of DDR3 phy limitation
the voltage change across DVFS and all shadow registers for DVFS on
DDR3 is not supported. Hence the emif kernel driver is not required,
so removing the DDR3 device file and emif nodes for uevm.
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Rebased on top of Benoit's latest tip and improved the subject, changelog
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83 +---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd388b1..8e50761 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -150,7 +150,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
mcspi1 {
};
--
1.7.9.5
[PATCH V3 4/4] ARM: dts: omap5-uevm: Add uart pinctrl data
From: Sourav Poddar sourav.pod...@ti.com
Booting omap5 uevm results in the following error
did not get pins for uart error: -19
This happens because omap5 uevm dts file is not adapted to use uart through
pinctrl
framework. Populating uart pinctrl data to get rid of the error.
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6e8bb86..927db1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -184,6 +184,32 @@
0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
;
};
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x60 (PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_cts */
+ 0x62 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_tx.uart1_cts */
+ 0x64 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart1_rx.uart1_rts */
+ 0x66 (PIN_OUTPUT | MUX_MODE0) /* uart1_rx.uart1_rts */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x19a (PIN_OUTPUT | MUX_MODE0) /*
uart3_rts_irsd.uart3_tx_irtx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart3_rx_irrx.uart3_usbb3_hsic */
+ ;
+ };
+
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_rx.uart5_rx */
+ 0x172 (PIN_OUTPUT | MUX_MODE0) /* uart5_tx.uart5_tx */
+ 0x174 (PIN_INPUT_PULLUP | MUX_MODE0) /*
uart5_cts.uart5_rts */
+ 0x176 (PIN_OUTPUT | MUX_MODE0) /* uart5_cts.uart5_rts */
+ ;
+ };
+
};
omap5_pmx_wkup {
@@ -268,3 +294,18 @@
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
};
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart3 {
+pinctrl-names = default;
+pinctrl-0 = uart3_pins;
+};
+
+uart5 {
+pinctrl-names = default;
+pinctrl-0 = uart5_pins;
+};
--
1.7.9.5
--
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
[PATCH V3 0/4] ARM: dts: omap5: Cleanup and updates for DT files
uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 1.7.9.5 -- 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
[PATCH V3 2/4] ARM: dts: omap5-uevm: Add USB Host support
From: Roger Quadros rog...@ti.com
Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.
Also provide pin multiplexer information for the USB host
pins.
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 70 ++
arch/arm/boot/dts/omap5.dtsi | 30
2 files changed, 100 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..a31e42f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,40 @@
regulator-max-microvolt = 300;
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ };
+
+ /* HS USB Port 3 RESET */
+ hsusb3_reset: hsusb3_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb3_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 3 */
+ hsusb3_phy: hsusb3_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb3_reset;
+ };
+
};
omap5_pmx_core {
@@ -35,6 +69,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+ usbhost_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +155,32 @@
0x16c (PIN_INPUT | MUX_MODE1) /* mcspi2_cs */
;
};
+
+ usbhost_pins: pinmux_usbhost_pins {
+ pinctrl-single,pins =
+ 0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
+ 0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data */
+
+ 0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe */
+ 0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data */
+
+ 0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 HUB_NRESET */
+ 0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
+ ;
+ };
+};
+
+omap5_pmx_wkup {
+ pinctrl-names = default;
+ pinctrl-0 =
+ usbhost_wkup_pins
+ ;
+
+ usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+ pinctrl-single,pins =
+ 0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub
clk */
+ ;
+ };
};
mmc1 {
@@ -164,6 +225,15 @@
status = disabled;
};
+usbhshost {
+ port2-mode = ehci-hsic;
+ port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy hsusb3_phy;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..accab62 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg
[PATCH V3 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED
From: Dan Murphy dmur...@ti.com
Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.
Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a31e42f..6e8bb86 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -59,6 +59,15 @@
reset-supply = hsusb3_reset;
};
+ leds {
+ compatible = gpio-leds;
+ led@1 {
+ label = omap5:blue:usr1;
+ gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1
LED */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
omap5_pmx_core {
@@ -70,6 +79,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+ led_gpio_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -168,6 +178,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
;
};
+
+ led_gpio_pins: pinmux_led_gpio_pins {
+ pinctrl-single,pins =
+ 0x196 (PIN_OUTPUT | MUX_MODE6) /*
uart3_cts_rctx.gpio5_153 */
+ ;
+ };
};
omap5_pmx_wkup {
--
1.7.9.5
--
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
Re: [PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On Friday 07 June 2013 05:36 PM, Benoit Cousson wrote: On 06/06/2013 07:48 PM, Sricharan R wrote: uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Could you update your branch before reposting, I pulled a Makefile fix for AM5xx that prevents your patches to be applied properly. Ok, rebased and posted V3. Regards, Sricharan -- 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
Re: [PATCH V2 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm
On Friday 07 June 2013 05:33 PM, Benoit Cousson wrote: Hi Sricharan, On 06/06/2013 07:48 PM, Sricharan R wrote: The uevm is the official board supported for the OMAP5 soc in mainline. The uevm has an OMAP5432 with a DDR3 memory. Renaming the board dts file and adding the following cleanups. OK, so in fact you are not just renaming the board file, you are using the previous board EVM DTS to describe a completely different board. You are recycling the old non supported EVM. You should update the subject and changelog to reflect that, because that's rather confusing. Ok, reposted V3. * There are no devices connected on I2C 2,3,4 buses. So remove the pinmux data for the same. * DDR3 memory is used in the uevm. Neither DVFS or temperature polling is supported with DDR3. So remove the DDR3 device and emif nodes. You should explain why. I don't think this is obvious for people outside TI. Ok, updated this in V3. Regards, Sricharan -- 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
Re: [PATCH V3 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On Friday 07 June 2013 08:21 PM, Benoit Cousson wrote: Thanks for the quick update. I've just applied the series in my for_3.11/dts branch. Thanks.. Regards, Sricharan Regards, Benoit On 06/07/2013 03:22 PM, Sricharan R wrote: uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts -- 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
[PATCH] spi: omap2-mcspi: Skip platform_get_resource_byname() for dt case
McSPI driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue comes out when dma entries are removed from the hwmod data.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index e4829aa..99172d2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1275,25 +1275,31 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
struct resource *dma_res;
sprintf(dma_rx_ch_name, rx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_rx_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA RX channel\n);
- status = -ENODEV;
- break;
+
+ if (!pdev-dev.of_node) {
+ dma_res = platform_get_resource_byname(pdev,
+ IORESOURCE_DMA, dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev, cannot get DMA RX
channel\n);
+ status = -ENODEV;
+ break;
+ }
+ mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
}
- mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
sprintf(dma_tx_ch_name, tx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_tx_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA TX channel\n);
- status = -ENODEV;
- break;
- }
- mcspi-dma_channels[i].dma_tx_sync_dev = dma_res-start;
+ if (!pdev-dev.of_node) {
+ dma_res = platform_get_resource_byname(pdev,
+ IORESOURCE_DMA, dma_tx_ch_name);
+
+ if (!dma_res) {
+ dev_dbg(pdev-dev, cannot get DMA TX
channel\n);
+ status = -ENODEV;
+ break;
+ }
+ mcspi-dma_channels[i].dma_tx_sync_dev = dma_res-start;
+ }
}
if (status 0)
--
1.7.9.5
--
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
Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Hi, On Saturday 08 June 2013 12:14 AM, Santosh Shilimkar wrote: On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130607 11:20]: On Friday 07 June 2013 01:50 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130607 09:35]: * Paul Walmsley p...@pwsan.com [130607 05:38]: On Fri, 7 Jun 2013, Sricharan R wrote: - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data is stripped from OMAP4 SOC hwmod data file. - The devices which are still missing the device tree bindings, address space entries are not removed yet. When such devices add the dt bindings, respective address space data can be deleted. - Also other unnecessary hwmods like firewalls are removed as a part of this. Since emif was getting registered only because of this firewalls links, the mpu-emif direct link is added now. The above update, results in reduction of about ~1650 lines of code. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Can't test this one since I don't have an OMAP4 DT config set up in the testbed yet. Maybe will add that to the testbed after the v3.10 release. OK thanks, applying into omap-for-v3.11/cleanup. I had to undo the following parts to avoid regressions on omap4sdp. Can you please follow up on fixing the related issues so the fixup won't be needed? Seems to work now the same way as earlier for both omap4sdp and blaze es, except for DSS, which seems to be a separate issue as posted by Tomi. Pushed out now to omap-for-v3.11/cleanup. Thats strange. You shouldn't need those fixes since that data is expected to be coming from DT. Sricharan, Can you please try out the patch against Tony's V3.11/clean-up branch and see whats missing there. Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. regards, Santosh The issue is that mmc, spi drivers try to get the 'dma' request number from get_platform_resource, which fails if hwmod has not populated the data. There are patches already from Balaji [1] for hsmmc, Matt Porter [2] mcspi for adapting the drivers for Dma engine. Dma engine gets the data from DT. [1] http://comments.gmane.org/gmane.linux.kernel.mmc/20378 [2] http://www.spinics.net/lists/linux-omap/msg87634.html [1] is already in mmc-next for 3.10 branch. Then one more patch for spi [3] is required for completing this. This is similar to the patch done for mmc to skip the get_platform_resource call in case of DT. [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90112.html Regards, Sricharan -- 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
[PATCH] ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods
Commit '3b9b10151c6838af52244cec4af41a938bb5b7ec' cleaned up the
data file to remove all irq and dma entries for all hwmods, which
are now populated by DT. But mcspi and mmc irq, dma entries were
retained since MMC, NFS boot was not working. Since it is root caused
to be an issue with only DMA entries [1], irq can be safely removed.
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90115.html
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54
1 file changed, 54 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5f5d631..11e579b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1747,11 +1747,6 @@ static struct omap_hwmod_class
omap44xx_mcspi_hwmod_class = {
};
/* mcspi1 */
-static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
- { .irq = 65 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
{ .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
@@ -1773,7 +1768,6 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
.name = mcspi1,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi1_irqs,
.sdma_reqs = omap44xx_mcspi1_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1787,11 +1781,6 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
};
/* mcspi2 */
-static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
- { .irq = 66 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
{ .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
@@ -1809,7 +1798,6 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
.name = mcspi2,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi2_irqs,
.sdma_reqs = omap44xx_mcspi2_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1823,11 +1811,6 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
};
/* mcspi3 */
-static struct omap_hwmod_irq_info omap44xx_mcspi3_irqs[] = {
- { .irq = 91 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi3_sdma_reqs[] = {
{ .name = tx0, .dma_req = 14 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 15 + OMAP44XX_DMA_REQ_START },
@@ -1845,7 +1828,6 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
.name = mcspi3,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi3_irqs,
.sdma_reqs = omap44xx_mcspi3_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1859,11 +1841,6 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
};
/* mcspi4 */
-static struct omap_hwmod_irq_info omap44xx_mcspi4_irqs[] = {
- { .irq = 48 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mcspi4_sdma_reqs[] = {
{ .name = tx0, .dma_req = 69 + OMAP44XX_DMA_REQ_START },
{ .name = rx0, .dma_req = 70 + OMAP44XX_DMA_REQ_START },
@@ -1879,7 +1856,6 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
.name = mcspi4,
.class = omap44xx_mcspi_hwmod_class,
.clkdm_name = l4_per_clkdm,
- .mpu_irqs = omap44xx_mcspi4_irqs,
.sdma_reqs = omap44xx_mcspi4_sdma_reqs,
.main_clk = func_48m_fclk,
.prcm = {
@@ -1915,11 +1891,6 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class
= {
};
/* mmc1 */
-static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
- { .irq = 83 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct omap_hwmod_dma_info omap44xx_mmc1_sdma_reqs[] = {
{ .name = tx, .dma_req = 60 + OMAP44XX_DMA_REQ_START },
{ .name = rx, .dma_req = 61 + OMAP44XX_DMA_REQ_START },
@@ -1935,7 +1906,6 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.name = mmc1,
.class = omap44xx_mmc_hwmod_class,
.clkdm_name = l3_init_clkdm,
- .mpu_irqs = omap44xx_mmc1_irqs,
.sdma_reqs = omap44xx_mmc1_sdma_reqs,
.main_clk = hsmmc1_fclk,
.prcm = {
@@ -1949,11 +1919,6 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
};
/* mmc2 */
-static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
- { .irq = 86 + OMAP44XX_IRQ_GIC_START },
- { .irq = -1 }
-};
-
static struct
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Hi Tony, On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130612 09:37]: * Ming Lei tom.leim...@gmail.com [130603 08:34]: Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote: We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted to prompt fine. Hardware: Pandaboard A1 dtb: omap4-panda.dtb git pull on linux-next branch was not working though. Regards, Sricharan -- 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
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: Hi Tony, On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130612 09:37]: * Ming Lei tom.leim...@gmail.com [130603 08:34]: Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote: We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted to prompt fine. Hardware: Pandaboard A1 dtb: omap4-panda.dtb git pull on linux-next branch was not working though. Ok, tested in linux-next as well and it booted fine with DTB. HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB Booted with ramdisk and mmc FS commit c04efed734409f5a44715b54a6ca1b54b0ccf215 Author: Stephen Rothwell s...@canb.auug.org.au Date: Fri Jun 7 16:40:02 2013 +1000 Add linux-next specific files for 20130607 Regards, Sricharan -- 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
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Friday 14 June 2013 07:28 PM, Ming Lei wrote: On Fri, Jun 14, 2013 at 9:31 PM, Ming Lei tom.leim...@gmail.com wrote: On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R r.sricha...@ti.com wrote: On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: Hi Tony, On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130612 09:37]: * Ming Lei tom.leim...@gmail.com [130603 08:34]: Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote: We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted to prompt fine. Hardware: Pandaboard A1 dtb: omap4-panda.dtb git pull on linux-next branch was not working though. Ok, tested in linux-next as well and it booted fine with DTB. HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB Booted with ramdisk and mmc FS commit c04efed734409f5a44715b54a6ca1b54b0ccf215 Author: Stephen Rothwell s...@canb.auug.org.au Date: Fri Jun 7 16:40:02 2013 +1000 Add linux-next specific files for 20130607 Looks linux-next-20130607 is broken, see below: LD [M] drivers/usb/gadget/g_ncm.o drivers/usb/musb/omap2430.c: In function 'omap2430_probe': drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared (first use in this function) drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb/omap2430.c:571:2: error: bit-field 'anonymous' width not an integer constant drivers/usb/musb/omap2430.c:585:4: error: bit-field 'anonymous' width not an integer constant make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [drivers/usb/musb] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 install kernel and modules DEPMOD 3.10.0-rc4-next-20130607+ Even I disable musb so that kernel building is OK, but the kernel with dtb still can't boot, see attachment 'dmesg' and config. Thanks, I am not sure how both of us are different. I was testing 20130607 with an omap2plusdefconfig. Also i was using a minimal busy box file system.. Is there anything specific FS that you want me to try ? I am using the latest u-boot version. U-Boot SPL 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) OMAP4430 ES2.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) CPU : OMAP4430 ES2.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # Panda # setenv bootargs root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x8160,20M ramdisk_size=20480 earlyprintk Panda # mmc dev 0 mmc0 is current device Panda # fatload mmc 0 0x8030 uImage reading uImage 4394007 bytes read in 300 ms (14 MiB/s) Panda # fatload mmc 0 0x8160 bb.raw reading bb.raw 1024 bytes read in 722 ms (13.5 MiB/s) Panda # bootm 0x8030 ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4393943 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00
Re: [PATCH] ARM: multi_v7: Add OMAP with ramdisk config bits
Hi, On Tuesday 18 June 2013 08:14 PM, Santosh Shilimkar wrote: On Tuesday 18 June 2013 04:24 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130612 14:14]: Add ramdisk fileystem related options which lets OMAP5 and Keystone SOCs to boot till shell with multi_v7_config. Please add also other v7 omaps. Should have done first place. Sorry. Will update other machines and after testing, repost it. Regards, Santosh Since CONFIG_ARCH_OMAP2PLUS=y is set in the patch, OMAP3, OMAP4 are getting enabled by default. I tested OMAP4 PANDA on mainline + multi_v7_config + above patch and it booted up fine. Regards, Sricharan -- 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
Re: [PATCH] ARM: multi_v7: Add OMAP with ramdisk config bits
On Monday 24 June 2013 08:03 PM, Sricharan R wrote: Hi, On Tuesday 18 June 2013 08:14 PM, Santosh Shilimkar wrote: On Tuesday 18 June 2013 04:24 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130612 14:14]: Add ramdisk fileystem related options which lets OMAP5 and Keystone SOCs to boot till shell with multi_v7_config. Please add also other v7 omaps. Should have done first place. Sorry. Will update other machines and after testing, repost it. Regards, Santosh Since CONFIG_ARCH_OMAP2PLUS=y is set in the patch, OMAP3, OMAP4 are getting enabled by default. I tested OMAP4 PANDA on mainline + multi_v7_config + above patch and it booted up fine. Also tested on OMAP3 beagle-xm and beagle-bone black (am335x-bone.dtb) and booted up fine. Regards, Sricharan -- 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
Re: [PATCH 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
On Sunday 14 July 2013 05:37 PM, Kevin Hilman wrote: On 07/09/2013 08:27 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs. In order for the gpiolib to detect and initialize these additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set to 512 instead of present 256. nit: the patch itself doesn't change 256 to 512, but just adds another Kconfig default. Kevin hmm, ok. Will reword the $subject and commit accordingly Regards, Sricharan Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5ef7af0..9faed52 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1599,7 +1599,7 @@ config LOCAL_TIMERS config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA -default 512 if SOC_OMAP5 +default 512 if SOC_OMAP5 || SOC_DRA7XX default 512 if ARCH_KEYSTONE default 392 if ARCH_U8500 default 352 if ARCH_VT8500 -- 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
[PATCH 0/3] Add crossbar driver
Some socs have a large number of interrupts/dma requests to service the needs of its many peripherals and subsystems. All of the requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt/dma controllers are preceded by an IRQ/DMA CROSSBAR that provides flexibility in muxing the device requests to the controller inputs. This series adds a crossbar driver and the DT bindings for the same. Also the DT nodes for DRA7xx SOC which has a IRQ/DMA crossbar has been added here. This series is on top of the basic DRA support from Rajendra [1][2] [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100763 [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/100773 Sricharan R (3): misc: Add crossbar driver ARM: dts: DRA: Add crossbar device binding ARM: DRA: Enable crossbar driver for dra soc .../devicetree/bindings/arm/omap/crossbar.txt | 24 ++ arch/arm/boot/dts/dra7.dtsi| 19 ++ arch/arm/mach-omap2/Kconfig|1 + drivers/misc/Kconfig |8 + drivers/misc/Makefile |1 + drivers/misc/crossbar.c| 258 include/linux/crossbar.h | 71 ++ 7 files changed, 382 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt create mode 100644 drivers/misc/crossbar.c create mode 100644 include/linux/crossbar.h -- 1.7.9.5 -- 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
[PATCH 2/3] ARM: dts: DRA: Add crossbar device binding
This adds the irq/dma crossbar device nodes.
There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. On POR, there are some mappings which
are done by default. Those peripherals which do not have a
mapping on POR, should be configured to route its requests
using the crossbar control registers.
The irq/dma mapping for some peripherals are
added with the crossbar nodes here.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..e6208b4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -85,6 +85,25 @@
ranges;
ti,hwmods = l3_main_1, l3_main_2;
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = crossbar;
+ crossbar-name = mpu-irq;
+ reg = 0x4a002a48 0x0130;
+ reg-width = 16;
+ crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9
0x12c,
+mpu-irq, mcasp3-arevt, 0x9e 0x96
0x12a,
+mpu-irq, mcasp3-axevt, 0x9d 0x97
0x128;
+ };
+
+ crossbar_dma: dmareq@4a002b78 {
+ compatible = crossbar;
+ crossbar-name = dma-req;
+ reg = 0x4a002b78 0x0100;
+ reg-width = 16;
+ crossbar-lines = dma-req, mcasp3-rx, 0x7e 0x84
0xfc,
+dma-req, mcasp3-tx, 0x7d 0x85
0xfa;
+ };
+
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
reg = 0x4ae04000 0x40;
--
1.7.9.5
--
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
[PATCH 3/3] ARM: DRA7xx: Enable crossbar driver for the soc
Enable the crossbar driver to handle the irq/dma crossbar devices in the soc. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 80aaadc..3def350 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.9.5 -- 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
[PATCH 1/3] misc: Add crossbar driver
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg: Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+ crossbar_mpu: mpuirq@4a002a48 {
+ compatible = crossbar;
+ crossbar-name = mpu-irq;
+ reg = 0x4a002a48 0x0130;
+ reg-width = 16;
+ crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9
0x12c,
+mpu-irq, mcasp3-arevt, 0x9e 0x96
0x12a,
+mpu-irq, mcasp3-axevt, 0x9d 0x97
0x128;
+ };
+
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c002d86..de89bff 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,6 +527,14 @@ config SRAM
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
+config CROSSBAR
+ bool on-chip crossbar driver
+ select REGMAP_MMIO
+ help
+ This driver is for IRQ/DMA crossbar devices which is responsible for
+ muxing the irq/dma requests from external peripherals to the
corresponding
+ controller's inputs.
+
source drivers/misc/c2port/Kconfig
source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c235d5b..37ce1b8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
+obj-$(CONFIG_CROSSBAR) += crossbar.o
diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c
new file mode 100644
index 000..c0a7e83
--- /dev/null
+++ b/drivers/misc/crossbar.c
@@ -0,0 +1,258 @@
+/*
+ * IRQ/DMA CROSSBAR DRIVER
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Sricharan R r.sricha...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote: On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: Since the cross-bar is not limited t0 IRQ lines and applicable for DMA request lines as well, making it IRQ chip doesn't make sense. Its not typical pin control functionality either but at least that framework is much closer to consider as an option. Actually its more of setting up the IRQ and DMA pins maps once at boot for a given SOC based on chosen configuration by the board. So I am leaning towards pinctrl as well. Just haven't thought enough about whether thats the best approach. CC'ing Linus W and Tony L whether we can use pinctrl framework for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. I also thought of using the pinctrl itself. But then i wanted to have the error handling as well, hence did this. Regards, Sricharan -- 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
Re: [PATCH 1/3] misc: Add crossbar driver
Hi,
On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.
The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.
The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets
mapped
during the crossbar device's probe. The mappings can also be specified by
adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/crossbar.c| 258
include/linux/crossbar.h | 71 ++
5 files changed, 362 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/omap/crossbar.txt
create mode 100644 drivers/misc/crossbar.c
create mode 100644 include/linux/crossbar.h
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be ti,dra-crossbar
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines: Default mappings.Should contain the crossbar-name
+ device name, int/dma request number, crossbar number,
+ register offset in the same order.
+
+Examples:
+crossbar_mpu: mpuirq@4a002a48 {
+compatible = crossbar;
+crossbar-name = mpu-irq;
+reg = 0x4a002a48 0x0130;
+reg-width = 16;
+crossbar-lines = mpu-irq, rtc-ss-alarm, 0x9f 0xd9 0x12c,
+ mpu-irq, mcasp3-arevt, 0x9e 0x96 0x12a,
+ mpu-irq, mcasp3-axevt, 0x9d 0x97 0x128;
+};
I carry forward my TI internal objection to this approach:
NAK.
DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is
as follows:
hardware IP block -interrupt line- IRQ Cross bar - GIC IRQ line -- MPU
IRQ.
What we have done today for DRA is to provide IRQ numbers as direct maps
from hardware IP block to GIC based on default IRQ cross bar mapping.
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
Now, think of a product that wants to use UART10 instead of UART1, SoC
design allows you do that by doing a remapping of GIC interrupt to UART10 -
which is awesome.
Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a fancy way - why the heck would I
want to do that when u-boot allows me to do the same thing in uEnv.txt
Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.
Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial@4806a000 {
snip
+interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
we should be able to do the following:
uart1: serial@4806a000 {
snip
+interrupts = TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH;
and not worry about the GIC interrupt number used
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon n...@ti.com wrote:
I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as its IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = ...;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = intc;
interrupts = 0 0 IRQ_TYPE_LEVEL_HIGH,
0 1 IRQ_TYPE_LEVEL_HIGH,
0 2 IRQ_TYPE_LEVEL_HIGH,
0 n IRQ_TYPE_LEVEL_HIGH;
};
uart0: serial@0 {
compatible = ...;
interrupt-parent = crossbar;
interrupts = 1234;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Thanks for this.
Was thinking of a similar kind of approach with irqchip.
But then, there was a GAP since crossbar does not have an irq unlike
other irqchips. But as you said this can be done by setting the crossbar
to map and receive the GIC interrupts and then direct to devices.
Only thing is, this is fine for IRQs, and something different has to be done
for DMA crossbars again. Also when we allocate dynamically here,
finding out a irq line when there is no free line is a question.
With the other approach of using/extending the pinctrl framework that you
gave, it is good to handle both irqs/dma. I looked at the other example in
drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
from the platform. I initially started with something similar, where the data
was passed statically from DT and a driver to use that. So now it looks good
to extend the pinctrl fw. I will try a approach for that first and see how it
looks.
Regards,
Sricharan
--
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
Re: [PATCH 1/3] misc: Add crossbar driver
On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Regards, Sricharan -- 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
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()is_dra7xx()
+# define soc_is_dra75x()is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
Regards,
Sricharan
memory {
device_type = memory;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..a7bc906 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,7 +17,7 @@
#address-cells = 1;
#size-cells = 1;
- compatible = ti,omap5;
+ compatible = ti,omap5432-es2.0, ti,omap5430-es2.0, ti,omap5;
interrupt-parent = gic;
aliases {
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..ee94309 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
pr_info(%s %s\n, soc_name, soc_rev);
}
-void __init omap5xxx_check_revision(void)
-{
- u32 idcode;
- u16 hawkeye;
- u8 rev;
-
- idcode = read_tap_reg(OMAP_TAP_IDCODE);
- hawkeye = (idcode 12) 0x;
- rev = (idcode 28) 0xff;
- switch (hawkeye) {
- case 0xb942:
- switch (rev) {
- case 0:
- omap_revision = OMAP5430_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5430_REV_ES2_0;
- }
- break;
-
- case 0xb998:
- switch (rev) {
- case 0:
- omap_revision = OMAP5432_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5432_REV_ES2_0;
- }
- break;
-
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP5430_REV_ES2_0;
- }
-
- sprintf(soc_name, OMAP%04x, omap_rev() 16);
- sprintf(soc_rev, ES%d.0, (omap_rev() 12) 0xf);
-
- pr_info(%s %s\n, soc_name, soc_rev);
-}
-
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..aa28940 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
#ifdef CONFIG_SOC_OMAP5
void __init omap5_init_early(void)
{
- omap2_set_globals_tap(OMAP54XX_CLASS,
- OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
+ omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
@@ -644,7 +643,6 @@ void __init omap5_init_early(void)
omap_prm_base_init();
omap_cm_base_init();
omap44xx_prm_init();
- omap5xxx_check_revision();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..b8339ad 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -35,6 +35,7 @@
#ifndef __ASSEMBLY__
#include linux/bitops.h
+#include linux/of.h
/*
* Test if multicore OMAP support is needed
@@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_CLASS(44xx, 0x44)
IS_AM_CLASS(35xx, 0x35)
-IS_OMAP_CLASS(54xx, 0x54)
IS_AM_CLASS(33xx, 0x33)
IS_AM_CLASS(43xx, 0x43)
@@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
IS_OMAP_SUBCLASS(447x, 0x447)
-IS_OMAP_SUBCLASS(543x, 0x543)
IS_TI_SUBCLASS(816x, 0x816)
IS_TI_SUBCLASS(814x, 0x814)
@@
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x()is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx() is_dra7xx()
+# define soc_is_dra75x() is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
Regards,
Sricharan
--
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
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi,
On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()is_dra7xx()
+# define soc_is_dra75x()is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
s
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
do we really production socketed boards? Well, at least Blaze has such
thing. But do we have too many differences that need to be trated at
arch/arm or should/could those be handled by reading IP's revision
register (e.g. usb host erratas)
OMAP4 SDP is socketed as well.
Ya, revision checks used only in few places and as you said
we handle them using IP revisions, but that we have to look and clean
up those places, if we really intend to do this for other socs.
Regards,
Sricharan
--
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
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. Regards, Sricharan -- 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
Re: [PATCH 1/3] misc: Add crossbar driver
Hi Linus, On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernelm=137442541628641w=2 (...) I don't see how you can make this happen with an irqchip infrastructure. I think my post above describes this. Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, SIC, IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. Ok, this is a typical example of irqchip cascaded. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. We can model crossbar as irqchip and gic as its interrupt parent and peripherals to have crossbar as interrupt-parent. peripherals will do request_irq(crossbar_number) | | crossbar_unmask() | | maps crossbar number- to interrupt number and calls request_irq(int_no, crossbar_handler,..) crossbar_handler(interrupt number) | | get crossbar number from interrupt number | | handle_irq(crossbar_domain(crossbar number)) So this means a extra dummy handler. Also the concern is by modelling it as irqchip, we will have to find a different solution for DMA crossbar. Regards, Sricharan -- 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
Re: [PATCH 1/3] misc: Add crossbar driver
Hi, On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: maps crossbar number- to interrupt number and calls request_irq(int_no, crossbar_handler,..) So will this mapping happen based on some data passed from DT or just based on whats available when the device does a request_irq()? If its based on whats available then I see an issue when you need to remap something thats already mapped by default (and not used) since you run out of all free ones. Yes, when done based on what is available then there is a problem when we run out of free ones because we do not know which one to replace. I was thinking of something like this, 1) DT would give a list of all free ones, and also if some are mapped as default and not used, mark those also as free. 2) While mapping see if it has a default mapping and use it. otherwise, pick from free list. This should be ok right ? Regards, Sricharan -- 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
Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: On Friday 23 August 2013 11:41 AM, Sricharan R wrote: Hi, On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: maps crossbar number- to interrupt number and calls request_irq(int_no, crossbar_handler,..) So will this mapping happen based on some data passed from DT or just based on whats available when the device does a request_irq()? If its based on whats available then I see an issue when you need to remap something thats already mapped by default (and not used) since you run out of all free ones. Yes, when done based on what is available then there is a problem when we run out of free ones because we do not know which one to replace. I was thinking of something like this, 1) DT would give a list of all free ones, and also if some are mapped as default and not used, mark those also as free. 2) While mapping see if it has a default mapping and use it. otherwise, pick from free list. Since the entire DT is available to you at boot time, you should be able to find each node where interrupt-parent = crossbar and then allocate one of 0-160 GIC interrupt numbers for that node, no? Where would there be a need for default mapping and remapping? From one the mails in the thread the crossbar is completely flexible - any of the 320 crossbar interrupts can be mapped to any of the 160 GIC interrupts. Any GIC interrupts left after this boot-time scan can be added to an unused list for use with runtime DT fragments (when that support comes). Sorry if I misunderstood, but above proposal sounds like maintaining a separate free interrupt lines list in DT. That will quickly go out of sync. Say, peripheral x uses crossbar 1 and specifies this in DT. During boot crossbar 1 gets mapped int 10. So if by default some other crossbar has its interrupt mapped to 10, then it should be removed. Instead clear all crossbar registers once and mark all as free, then allocate only during request. Correct ?. In this the free no need to maintain any list. Regards, Sricharan -- 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
[RFC PATCH 2/4] ARM: DTS: DRA: Add crossbar device binding
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. This models the crossbar as an interrupt
controller. This a cascaded irqchip where the peripheral interrupt
lines are connected to the crossbar and the crossbar's outputs
are in turn connected to the GIC.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..da977e1 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -84,6 +84,7 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2;
+ interrupt-parent = crossbar_mpu;
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
@@ -491,5 +492,20 @@
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
};
+
+ crossbar_mpu: @4a02 {
+ compatible = crossbar-irqchip;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1;
+ #size-cells = 1;
+ };
+
};
};
--
1.7.9.5
--
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
[RFC PATCH 0/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. This series models the crossbar IP as a cascaded irqchip controller. The peripheral crossbar inputs are mapped on to the crossbar irq-domain. The driver then allocates a 'free' irq line and maps that to the actual interrupt controller's domain. So every external peripheral interrupt is routed through the crossbar handler. This series adds a crossbar driver and the DT bindings for the same. Also the DT nodes for DRA7xx SOC which has a IRQ crossbar has been added here. Sricharan R (4): DRIVERS: IRQCHIP: Add crossbar irqchip driver ARM: DTS: DRA: Add crossbar device binding ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs. ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx .../devicetree/bindings/arm/omap/irq-crossbar.txt | 39 ++ arch/arm/boot/dts/dra7.dtsi| 104 ++--- arch/arm/mach-omap2/Kconfig|1 + drivers/irqchip/Kconfig|9 + drivers/irqchip/Makefile |1 + drivers/irqchip/irq-crossbar.c | 407 6 files changed, 517 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c -- 1.7.9.5 -- 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
[RFC PATCH 4/4] ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx
Enable the crossbar irqchip driver for DRA7xx soc. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8413252..b602168 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select IRQCHIP_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.9.5 -- 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
[RFC PATCH 3/4] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index da977e1..2c541af 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
- interrupts = 0 12 0x4,
-0 13 0x4,
-0 14 0x4,
-0 15 0x4;
+ interrupts = 0 7 0x4,
+0 8 0x4,
+0 9 0x4,
+0 10 0x4;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -116,7 +116,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
- interrupts = 0 29 0x4;
+ interrupts = 0 24 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -127,7 +127,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
- interrupts = 0 30 0x4;
+ interrupts = 0 25 0x4;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -138,7 +138,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
- interrupts = 0 31 0x4;
+ interrupts = 0 26 0x4;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -149,7 +149,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
- interrupts = 0 32 0x4;
+ interrupts = 0 27 0x4;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -160,7 +160,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
- interrupts = 0 33 0x4;
+ interrupts = 0 28 0x4;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -171,7 +171,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
- interrupts = 0 34 0x4;
+ interrupts = 0 29 0x4;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
@@ -182,7 +182,7 @@
gpio7: gpio@48051000 {
compatible = ti,omap4-gpio;
reg = 0x48051000 0x200;
- interrupts = 0 35 0x4;
+ interrupts = 0 30 0x4;
ti,hwmods = gpio7;
gpio-controller;
#gpio-cells = 2;
@@ -193,7 +193,7 @@
gpio8: gpio@48053000 {
compatible = ti,omap4-gpio;
reg = 0x48053000 0x200;
- interrupts = 0 121 0x4;
+ interrupts = 0 116 0x4;
ti,hwmods = gpio8;
gpio-controller;
#gpio-cells = 2;
@@ -204,7 +204,7 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
- interrupts = 0 72 0x4;
+ interrupts = 0 67 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
@@ -212,7 +212,7 @@
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
reg = 0x4806c000 0x100;
- interrupts = 0 73 0x4;
+ interrupts = 0 68 0x4;
ti,hwmods
[RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This models the crossbar IP as a cascaded irqchip controller.
The peripheral crossbar inputs are mapped on to the crossbar irq-domain.
The driver then allocates a 'free' irq line and maps that to the
actual interrupt controller's domain. So every external peripheral interrupt
is routed through the crossbar handler.
GIC - CROSSBAR - PERIPHERAL INTERRUPT LINES
peripheral's irq_of_parse_and_map()
|
|
crossbar_xlate()
|
|
saves the interrupt properties passed
peripheral's request_irq(crossbar_number)
|
|
crossbar_request_irq
|
|
allocates free irq and maps it to parent domain
|
|
request_irq(mapped interrupt number)
gic_interrupt_hanadler
|
|
crossbar_irq(interrupt number)
|
|
get crossbar number from interrupt number
|
|
handle_irq(crossbar_domain(crossbar number))
The irqchip callback hooks added here are just a redirection to the
parent irqchip.
This adds a extra translation in the fast path. The maximum increase in
the average interrupt latency due to the same was measured as around 1.63us
on a cpu running at 1GHZ.
cat /proc/interrupts looks like this, with both crossbar and interrupt number
CPU0 CPU1
45:267 0 GIC OMAP UART0
205:267 0 CROSSBAR OMAP UART0
Cc: Thomas Gleixner t...@linutronix.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is lockdep warning during the boot. This is because we try to
do one request_irq with in another and that results in kmalloc being
called from an atomic context, which generates the warning.
Any suggestions to overcome this will help.
WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xe8/0x108()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
.../devicetree/bindings/arm/omap/irq-crossbar.txt | 39 ++
drivers/irqchip/Kconfig|9 +
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-crossbar.c | 407
4 files changed, 456 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
create mode 100644 drivers/irqchip/irq-crossbar.c
diff --git a/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
new file mode 100644
index 000..5d465cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
@@ -0,0 +1,39 @@
+* IRQ CROSSBAR
+
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be irq-crossbar
+- interrupt-parent: phandle to crossbar's interrupt parent.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupt-cells: Should be the same value as the interrupt parent.
+- reg: Base address and the size of the crossbar registers.
+- max-crossbar-lines: Total number of input lines of the crossbar.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: size of the crossbar registers.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+crossbar. These interrupt lines are reserved in the soc,
+so crossbar bar driver should not consider them as free
+lines.
+
+Examples:
+ crossbar_mpu: @4a02 {
+ compatible = irq-crossbar;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1
[PATCH] ARM: DRA7: realtime_counter: Add ratio registers for 20MHZ sys-clk frequency
The real time counter also called master counter, is a free-running counter. It produces the count used by the CPU local timer peripherals in the MPU cluster. The timer counts at a rate of 6.144 MHz. The ratio registers are missing for a sys-clk of 20MHZ which is used by DRA7 socs. So because of this, the counter was getting wrongly programmed for a sys-clk of 38.4Mhz(default). So adding the ratio registers for 20MHZ sys-clk. Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/timer.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index e1528a0..fd9238d 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -515,6 +515,10 @@ static void __init realtime_counter_init(void) num = 8; den = 25; break; + case 2000: + num = 192; + den = 625; + break; case 260: num = 384; den = 1625; -- 1.7.9.5 -- 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
[PATCH] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
host OS, as this will be propagated to the guests as well.
More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
So configuring this secure register for all the cpus here.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/omap-secure.h |2 ++
arch/arm/mach-omap2/omap-smp.c|9 +
arch/arm/mach-omap2/timer.c |6 ++
3 files changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index a171a5a..4de9a00 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,8 @@
#define OMAP5_MON_AMBA_IF_INDEX0x108
+#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX0x109
+
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 98a1146..00873b4 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -41,6 +41,8 @@
u16 pm44xx_errata;
+extern unsigned long arch_timer_freq;
+
/* SCU base address */
static void __iomem *scu_base;
@@ -66,6 +68,13 @@ static void __cpuinit omap4_secondary_init(unsigned int cpu)
4, 0, 0, 0, 0, 0);
/*
+* Configure the CNTFRQ register for the secondary cpu's which
+* indicates the frequency of the cpu local timers.
+*/
+ if (soc_is_omap54xx() || soc_is_dra7xx())
+ omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
+
+ /*
* Synchronise with the boot thread.
*/
spin_lock(boot_lock);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fd9238d..2c499f3 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -55,6 +55,7 @@
#include soc.h
#include common.h
#include powerdomain.h
+#include omap-secure.h
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -65,6 +66,7 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+unsigned long arch_timer_freq;
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
@@ -546,7 +548,11 @@ static void __init realtime_counter_init(void)
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+ arch_timer_freq = (rate / den) * num;
+
iounmap(base);
+
+ omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
}
#else
static inline void __init realtime_counter_init(void)
--
1.7.9.5
--
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
Re: [PATCH V2] ARM: dts: DRA7: provide arch-timer frequenecy parameter
Hi,
On Tuesday 17 September 2013 10:31 PM, Nishanth Menon wrote:
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
timer frequency via DT. Without a valid value arch_timer_init results
in div0 crash.
Cc: R Sricharan r.sricha...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on Benoit's for_3.13/dts branch.
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
Crash log: http://pastebin.com/B2sDauS9
V2: commit message update
V1: https://patchwork.kernel.org/patch/2903261/
arch/arm/boot/dts/dra7.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c98997b..71c2749 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -50,6 +50,7 @@
GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW);
+ clock-frequency = 6144000;
};
gic: interrupt-controller@48211000 {
This is not the right way to pass the frequency. In fact, initially the
frequency value was present
when the dts was added, but had to revert it back based on the feedbacks.
Please refer below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
Also posted the below patch to fix this,
http://marc.info/?l=linux-omapm=137950345528918w=2
Regards,
Sricharan
--
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
Re: [PATCH] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
On Wednesday 18 September 2013 07:01 PM, Santosh Shilimkar wrote:
On Wednesday 18 September 2013 07:23 AM, Sricharan R wrote:
The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
host OS, as this will be propagated to the guests as well.
Its not host OS but ROM code/secure code. Host OS is not
ideal place to set it up.
ok, so you are suggesting to re word this right ?
More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
So configuring this secure register for all the cpus here.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/omap-secure.h |2 ++
arch/arm/mach-omap2/omap-smp.c|9 +
arch/arm/mach-omap2/timer.c |6 ++
3 files changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index a171a5a..4de9a00 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,8 @@
#define OMAP5_MON_AMBA_IF_INDEX 0x108
+#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX 0x109
+
Nice. Looks like OMAP5 ES2.0 addition which I missed.
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 98a1146..00873b4 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -41,6 +41,8 @@
u16 pm44xx_errata;
+extern unsigned long arch_timer_freq;
+
/* SCU base address */
static void __iomem *scu_base;
@@ -66,6 +68,13 @@ static void __cpuinit omap4_secondary_init(unsigned int
cpu)
4, 0, 0, 0, 0, 0);
/*
+ * Configure the CNTFRQ register for the secondary cpu's which
+ * indicates the frequency of the cpu local timers.
+ */
+if (soc_is_omap54xx() || soc_is_dra7xx())
CNTFREQ programming was not supported on OMAP5 ES1.0 and that was one
of the reason this parameter came into picture. So you need to skip
the ES1.0 here.
We do not intend to support ES1.0 right ? . ok then id.c needs to be
cleaned up to remove ES1.0 traces.
+omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
+
+/*
* Synchronise with the boot thread.
*/
spin_lock(boot_lock);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fd9238d..2c499f3 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -55,6 +55,7 @@
#include soc.h
#include common.h
#include powerdomain.h
+#include omap-secure.h
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET0x10
@@ -65,6 +66,7 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+unsigned long arch_timer_freq;
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
@@ -546,7 +548,11 @@ static void __init realtime_counter_init(void)
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+arch_timer_freq = (rate / den) * num;
+
iounmap(base);
+
+omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
Few problems with this approach..
1. CNTFREQ needs to be programmed on all CPUs. Even though arch-timer
code uses boot-cpu now thats not safe for guest which can start on
secondary CPUs. So please update this in secondary boot path as well.
The patch is doing this for secondary cpu's as well in the
call back omap4_secondary_init.
2. When you power cycle CPU, you will loose the value of this register
so you need to reprogram them on every CPU power up. Both DRA and OMAP5
doesn't support that part yet but do remember to patch that when
such support gets added.
oh ok. did not realize this. Will add the change for this then.
Can you please fix above comments and repost. I will ack that then.
Regards,
Santosh
Regards,
Sricharan
--
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
Re: [PATCH] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
On Wednesday 18 September 2013 07:19 PM, Santosh Shilimkar wrote:
On Wednesday 18 September 2013 09:44 AM, Sricharan R wrote:
On Wednesday 18 September 2013 07:01 PM, Santosh Shilimkar wrote:
On Wednesday 18 September 2013 07:23 AM, Sricharan R wrote:
The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
host OS, as this will be propagated to the guests as well.
Its not host OS but ROM code/secure code. Host OS is not
ideal place to set it up.
ok, so you are suggesting to re word this right ?
More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
So configuring this secure register for all the cpus here.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/omap-secure.h |2 ++
arch/arm/mach-omap2/omap-smp.c|9 +
arch/arm/mach-omap2/timer.c |6 ++
3 files changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index a171a5a..4de9a00 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,8 @@
#define OMAP5_MON_AMBA_IF_INDEX 0x108
+#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX 0x109
+
Nice. Looks like OMAP5 ES2.0 addition which I missed.
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-smp.c
b/arch/arm/mach-omap2/omap-smp.c
index 98a1146..00873b4 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -41,6 +41,8 @@
u16 pm44xx_errata;
+extern unsigned long arch_timer_freq;
+
/* SCU base address */
static void __iomem *scu_base;
@@ -66,6 +68,13 @@ static void __cpuinit omap4_secondary_init(unsigned int
cpu)
4, 0, 0, 0, 0, 0);
/*
+ * Configure the CNTFRQ register for the secondary cpu's which
+ * indicates the frequency of the cpu local timers.
+ */
+ if (soc_is_omap54xx() || soc_is_dra7xx())
CNTFREQ programming was not supported on OMAP5 ES1.0 and that was one
of the reason this parameter came into picture. So you need to skip
the ES1.0 here.
We do not intend to support ES1.0 right ? . ok then id.c needs to be
cleaned up to remove ES1.0 traces.
yes. With clean-up ES1.0, this can stay as is.
+ omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
+
+ /*
* Synchronise with the boot thread.
*/
spin_lock(boot_lock);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fd9238d..2c499f3 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -55,6 +55,7 @@
#include soc.h
#include common.h
#include powerdomain.h
+#include omap-secure.h
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -65,6 +66,7 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+unsigned long arch_timer_freq;
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
@@ -546,7 +548,11 @@ static void __init realtime_counter_init(void)
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+ arch_timer_freq = (rate / den) * num;
+
iounmap(base);
+
+ omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
Few problems with this approach..
1. CNTFREQ needs to be programmed on all CPUs. Even though arch-timer
code uses boot-cpu now thats not safe for guest which can start on
secondary CPUs. So please update this in secondary boot path as well.
The patch is doing this for secondary cpu's as well in the
call back omap4_secondary_init.
NM just pointed out this off-list.
2. When you power cycle CPU, you will loose the value of this register
so you need to reprogram them on every CPU power up. Both DRA and OMAP5
doesn't support that part yet but do remember to patch that when
such support gets added.
oh ok. did not realize this. Will add the change for this then.
Since PM isn't supported for now, the patch looks alright with ES1.0
support gets dropped. Just fix the change-log.
Feel free to add my ack on updated version.
Thanks. Will repost
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Hi Thomas,
On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner t...@linutronix.de wrote:
So why can't you make use of irq domains and have the whole routing
business implemented sanely?
What's needed is in gic_init_bases():
irq
if (of_property_read(node, routable_irqs, nr_routable_irqs) {
irq_domain_add_legacy(nr_gic_irqs);
} else {
irq_domain_add_legacy(nr_per_cpu_irqs);
irq_domain_add_linear(nr_routable_irqs);
}
Now that separate domain has an xlate function which grabs a free GIC
irq from a bitmap and returns the hardware irq number in the gic
space. The map/unmap callbacks take care of setting up / tearing down
the route in the crossbar.
This is obviously the right approach, it's exactly what .map should do
the only special thing here being that we have hardware to perform
the mapping ... bah why didn't I realize this :-(
Yours,
Linus Walleij
Thanks for the suggestion.
So as i understand this, this implies using the GIC domain itself and
add the support for dynamically routable irqs (like crossbar) with in the
GIC driver itself right ?
Regards,
Sricharan
--
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
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
Hi Thomas,
On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner t...@linutronix.de wrote:
So why can't you make use of irq domains and have the whole routing
business implemented sanely?
What's needed is in gic_init_bases():
irq
if (of_property_read(node, routable_irqs, nr_routable_irqs) {
irq_domain_add_legacy(nr_gic_irqs);
} else {
irq_domain_add_legacy(nr_per_cpu_irqs);
irq_domain_add_linear(nr_routable_irqs);
}
Now that separate domain has an xlate function which grabs a free GIC
irq from a bitmap and returns the hardware irq number in the gic
space. The map/unmap callbacks take care of setting up / tearing down
the route in the crossbar.
This is obviously the right approach, it's exactly what .map should do
the only special thing here being that we have hardware to perform
the mapping ... bah why didn't I realize this :-(
Yours,
Linus Walleij
Thanks for the suggestion.
So as i understand this, this implies using the GIC domain itself and
add the support for dynamically routable irqs (like crossbar) with in the
GIC driver itself right ?
Please ignore this. So the question was more of how to implement the
call outs in the case of routable irqs from map/ unmap callbacks.
I will look more here and come back.
Regards,
Sricharan
--
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
