* Felipe Balbi ba...@ti.com [140613 09:33]:
On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -0,0 +1,539 @@
+/*
+ * Copyright (C) 2014 Texas
* Paul Walmsley p...@pwsan.com [140615 20:19]:
Hi Tony,
The following changes since commit abf04af74a9f27a65172a43b43ccabcbc2bbdc39:
Merge tag 'scsi-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2014-06-14 19:49:48
-0500)
are available in the git repository
* Felipe Balbi ba...@ti.com [140613 09:17]:
From: Sathya Prakash M R sath...@ti.com
Add DSS hwmod data for AM43xx.
Cc: Andrew Morton a...@linux-foundation.org
Acked-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen
On 29 May 2014 10:27, Andreas Fenkart afenk...@gmail.com wrote:
Hi Balaji, Tony, Ulf, all
v14
- drop all ifdef/endif introduced by v13
-- rely on pinctrl_lookup_state to prevent ifdef CONFIG_PM
-- benefit: all code is compile tested no matter the configuration
-- drawback: require
* Arnd Bergmann a...@arndb.de [140613 09:02]:
Commit d941f86fad41b (ARM: l2c: AM43x: add L2 cache support) enabled
the L2 cache support for the am43xx SoC, but caused a build regression
when the driver for that cache controller is disabled:
arch/arm/mach-omap2/built-in.o: In function
Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more
than expected, which led to two OMAP specific bugs:
* Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
to have a configuration with ARCH_OMAP enabled but none of the specific
OMAP SoCs enabled, which
Still not seeing this branch being merged..
Oh crap, I see what's happened and it's completely my fault.
If you read the final merge commit carefully:
28fee3f: (Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16',
'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and
* Lee Jones lee.jo...@linaro.org [140616 03:19]:
Still not seeing this branch being merged..
Oh crap, I see what's happened and it's completely my fault.
If you read the final merge commit carefully:
28fee3f: (Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16',
* Nishanth Menon n...@ti.com [140530 06:19]:
On 05/30/2014 06:34 AM, Sricharan R wrote:
Hi,
On Tuesday 06 May 2014 10:22 PM, Tony Lindgren wrote:
* Sourav Poddar sourav.pod...@ti.com [140506 04:08]:
These add device tree entry for qspi controller driver on dra7-evm.
Thanks applying
* Arnd Bergmann a...@arndb.de [140616 03:06]:
Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more
than expected, which led to two OMAP specific bugs:
It seems the commit above is not -rc cycle material at least not without
proper testing. There's a good chance of breaking a
On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140616 03:06]:
Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more
than expected, which led to two OMAP specific bugs:
It seems the commit above is not -rc cycle material at least not
This series does some cleanups, fixes for handling two interrupts
getting mapped twice to same crossbar and provides support for
hardwired IRQ and crossbar definitions.
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10,
131, 132, 133 are direct wired to hardware blocks bypassing
From: Nishanth Menon n...@ti.com
The current crossbar description does not include the description
required for the consumer of the crossbar, a.k.a devices whoes events
pass through the crossbar into the GIC interrupt controller.
So, provide documentation for the same.
Signed-off-by: Nishanth
From: Nishanth Menon n...@ti.com
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in
If crossbar_of_init returns with a error, then set the cb pointer
to null.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index
From: Nishanth Menon n...@ti.com
Currently we attempt to map any crossbar value to an IRQ, however,
this is not correct from hardware perspective. There is a max crossbar
event number upto which hardware supports. So describe the same in
device tree using 'ti,max-crossbar-sources' property and
From: Nishanth Menon n...@ti.com
This is a basic check to ensure that crossbar register needs to be
written. This ensures that we have a common check which is used in
both map and unmap logic.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
From: Nishanth Menon n...@ti.com
crossbar_of_init always returns -ENOMEM in case of errors.
There can be other causes of failure like invalid data from
DT. So return a appropriate error value for that case.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Adding kerneldoc for unmap callback function.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Reworded the kerneldoc
drivers/irqchip/irq-crossbar.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index
From: Nishanth Menon n...@ti.com
Adding missing properties for kerneldoc (@write) and cleanup
of harmless warnings while we are here.
kerneldoc warnings:
Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description
on line:
* struct crossbar_device: crossbar device description
From: Nishanth Menon n...@ti.com
There is absolutely no need for crossbar driver to expose functions and
variables into global namespace. So make them all static
Also fix a couple of checkpatch warnings.
Fixes sparse warnings:
drivers/irqchip/irq-crossbar.c:129:29: warning: symbol
From: Nishanth Menon n...@ti.com
IS_ERR_VALUE makes sense only *if* there could be valid values in
negative error range. But in the cases that we do use it, there is no
such case. Just remove the same.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
* Arnd Bergmann a...@arndb.de [140616 04:18]:
On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140616 03:06]:
Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more
than expected, which led to two OMAP specific bugs:
It seems the
From: Nishanth Menon n...@ti.com
Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
middle will not result in spurious changes, so rename the error paths
as per the function it does.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
From: Nishanth Menon n...@ti.com
Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This makes the below bugs visible sooner.
class 1. address space errors - example:
reg = a size_b
ti,max-irqs = is a wrong parameter
class 2: irq-reserved list -
From: Nishanth Menon n...@ti.com
Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value
From: Nishanth Menon n...@ti.com
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by:
From: Nishanth Menon n...@ti.com
If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already
From: Nishanth Menon n...@ti.com
Today '0' is actually reserved, but may not be the same in the future.
So, use a flag to mark the GIC interrupts that are reserved.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |5
* Archit Taneja arc...@ti.com [140528 03:53]:
Currently, clock providers coming from CM, PRM, and SCRM are all initialized
in
prm_common.c.
Move the DT-match tables to their respective files, and create separate init
functions for each module.
Originally worked on by: Tero Kristo
* Nishanth Menon n...@ti.com [140529 12:07]:
Add support for DRA72x device DIEID. Currently these devices are
reported as DRA75/74 family of processors.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks applying into omap-for-v3.16/fixes.
Tony
---
(test using linux-next next-20140529
* Nishanth Menon n...@ti.com [140605 18:11]:
As per the Final production Data Manual for OMAP5432,
SWPS050F(APRIL 2014)
There are only two OPPs - 1GHz and 1.5GHz. the older OPP_LOW has been
completely descoped. The Nominal voltages are still correct though.
However, expectation for final
* Nishanth Menon n...@ti.com [140606 08:30]:
On 06/06/2014 04:52 AM, George Cherian wrote:
On 6/6/2014 12:23 PM, Nishanth Menon wrote:
On 06/06/2014 01:17 AM, George Cherian wrote:
AM437x EPOS evm use external clock for RMII interface.
Enable the same in DT.
Signed-off-by: George
* Brian Norris computersforpe...@gmail.com [140610 14:31]:
gic_init_irq() is no longer used as of:
commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren t...@atomide.com
Date: Thu May 30 12:53:05 2013 -0700
ARM: OMAP2+: Remove board-omap4panda.c
This series introduces DT support for crossbar device and
changes dra7 peripherals to use crossbar number instead of irq.
This depends on below driver fixes and cleanup series.
https://lkml.org/lkml/2014/6/16/218
[V2] Rebased on 3.15 mainline.
[V3] Added ti,irqs-skip property and
From: R Sricharan r.sricha...@ti.com
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 gic provides the support for such
IPs in the form of routable-irqs. So adding the property
here to gic node.
From: R Sricharan r.sricha...@ti.com
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
On 13/06/14 22:53, Paul Walmsley wrote:
Whatever we do to the (common, not DSS-specific) clock code to fix this
issue, it has to make sense independently of your specific DSS needs.
I agree. I think the fix (v1) makes sense for all users of the pll.
Correct me if I'm wrong, but the current
+linux-omap.
On 06/15/2014 08:44 PM, Axel Lin wrote:
Might be nice to have a commit message here.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/twl-regulator.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git
Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote:
I'd like to discuss moving our current library of cape devicetree
overlay sources into a single tree, including the boot .dtb files for
On 05/07/2014 01:20 PM, Peter Ujfalusi wrote:
Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.
Add the ATL device node at the same time for DRA7.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
This patch missed the merge window due to long dependency
Sricharan,
On Monday 16 June 2014 07:23 AM, Sricharan R wrote:
This series does some cleanups, fixes for handling two interrupts
getting mapped twice to same crossbar and provides support for
hardwired IRQ and crossbar definitions.
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6,
* Tero Kristo t-kri...@ti.com [140616 07:03]:
On 05/07/2014 01:20 PM, Peter Ujfalusi wrote:
Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.
Add the ATL device node at the same time for DRA7.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
This
* Tony Lindgren t...@atomide.com [140616 04:31]:
* Arnd Bergmann a...@arndb.de [140616 04:18]:
Let's see if others have similar opinions Rob's patch as a whole.
I'd still like to keep all the parts aside from the OMAP change
and just back out the change that caused the problems.
Hi,
On Sun, Jun 15, 2014 at 03:29:40AM +, Paul Walmsley wrote:
Hi,
On Fri, 13 Jun 2014, Felipe Balbi wrote:
On Sat, Jun 14, 2014 at 02:57:32AM +, Paul Walmsley wrote:
From: Sathya Prakash M R sath...@ti.com
Add DSS hwmod data for AM43xx.
Cc:
On Mon, Jun 16, 2014 at 9:17 AM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [140616 04:31]:
* Arnd Bergmann a...@arndb.de [140616 04:18]:
Let's see if others have similar opinions Rob's patch as a whole.
I'd still like to keep all the parts aside from the OMAP
On 06/15/2014 08:56 PM, Paul Walmsley wrote:
On Fri, 13 Jun 2014, Paul Walmsley wrote:
On Mon, 9 Jun 2014, Dave Gerlach wrote:
am43xx reset register layout is more similar to am33xx than omap4 so
use the am33xx functions for hwmod hardreset soc_ops rather than the
currently used omap4
Paul,
On 06/15/2014 11:43 PM, Paul Walmsley wrote:
Dave,
On Mon, 9 Jun 2014, Dave Gerlach wrote:
am43xx reset register layout is more similar to am33xx than omap4 so
use the am33xx functions for hwmod hardreset soc_ops rather than the
currently used omap4 functions. Without this,
Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.
Signed-off-by: David R. Piegdon
49 matches
Mail list logo