On 10/29/2013 06:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM, Tero Kristo wrote:
snip
Testing done:
- omap3-beagle: boot + suspend/resume (ret + off)
- omap4-panda-es: boot + suspend/resume
- omap5-uevm: boot
- dra7-evm: boot
- am335x-bone: boot
Test branches available:
tree:
On 10/29/2013 07:50 PM, Matt Sealey wrote:
On Fri, Oct 25, 2013 at 10:56 AM, Tero Kristo t-kri...@ti.com wrote:
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the
On Tue, Oct 29, 2013 at 11:59:57PM -0400, Brian Norris wrote:
Pekon/Ezequiel/others: please feel free to send any follow up cleanups
for this driver. I'll take a look at what Ezequiel has already sent
out and see if it's still applicable on top.
They won't. I'll prepare a new patch in top
On Friday 18 October 2013 09:27 PM, Daniel Mack wrote:
On 10/09/2013 10:14 PM, Joel Fernandes wrote:
On 10/09/2013 09:12 AM, Joel Fernandes wrote:
On 10/09/2013 02:38 AM, Daniel Mack wrote:
[..]
(And the 'v3' in the subject is really my bad, sorry - I only sent one
version of this patch
As it was discussed recently in the mailing list, the omap2-nand driver
currently
has an issue preventing proper ONFI detection of 16-bit devices (other drivers
may suffer from this same issue).
In an attempt to address such issue, this patch uses NAND_BUSWIDTH_AUTO
(actually discarding any DT
Because the device bus can be 8-bit or 16-bit width, yet ONFI detection
cannot work in 16-bit mode, we need to set the NAND_BUSWIDTH_AUTO option
which allows proper initialization configuration.
Once the bus width is detected, nand_scan_ident() updates the nand_chip struct
'option' field to use
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 27 Oct 2013 12:47:53 +0100, Pavel Machek pa...@ucw.cz wrote:
+#if IS_ENABLED(CONFIG_OF)
I'm probably missing something here, but why not #ifdef CONFIG_OF?
I have been told for other drivers, that IS_ENABLED() is
the prefered way to check for configuration these days.
On Wed 2013-10-30 06:53:07, Grant Likely wrote:
On Sun, 27 Oct 2013 12:47:53 +0100, Pavel Machek pa...@ucw.cz wrote:
+#if IS_ENABLED(CONFIG_OF)
I'm probably missing something here, but why not #ifdef CONFIG_OF?
I have been told for other drivers, that IS_ENABLED() is
the
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
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/mach-omap2/Kconfig|2 +-
arch/arm/mach-omap2/omap4-common.c |
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.
Cc: Benoit Cousson bcous...@baylibre.com
Cc:
The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically
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.
Cc: Benoit
In some socs the gic can be preceded by a crossbar IP which
routes the peripheral interrupts to the gic inputs. The peripheral
interrupts are associated with a fixed crossbar input line and the
crossbar routes that to one of the free gic input line.
The DT entries for peripherals provides the
On 10/30/2013 03:23 AM, Tero Kristo wrote:
On 10/29/2013 06:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM, Tero Kristo wrote:
snip
Testing done:
- omap3-beagle: boot + suspend/resume (ret + off)
- omap4-panda-es: boot + suspend/resume
- omap5-uevm: boot
- dra7-evm: boot
-
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
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
On Wed, 30 Oct 2013, Sricharan R wrote:
@@ -700,11 +709,22 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
+ if (!intspec[0]) {
On Wed, 30 Oct 2013, Sricharan R wrote:
+static inline const u32 allocate_free_irq(int cb_no)
I understand the static inline part, but const u32 is more than
fishy. What's wrong with static inline int ?
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++) {
+ if
On Wed, Oct 30, 2013 at 3:29 AM, Tero Kristo t-kri...@ti.com wrote:
On 10/29/2013 07:50 PM, Matt Sealey wrote:
I have one question here, what makes this part of the patch
TI-specific at all except the definition of the structure ti_dt_clk?
Mapping DT clocks to generic clkdev legacy namings
Hi,
On Wed, Oct 30, 2013 at 06:53:07AM -0300, Ezequiel Garcia wrote:
As it was discussed recently in the mailing list, the omap2-nand driver
currently
has an issue preventing proper ONFI detection of 16-bit devices (other drivers
may suffer from this same issue).
First of all, thanks for
On 10/30/2013 10:00 AM, Nishanth Menon wrote:
On 10/30/2013 03:23 AM, Tero Kristo wrote:
On 10/29/2013 06:19 PM, Nishanth Menon wrote:
On 10/25/2013 10:56 AM, Tero Kristo wrote:
snip
Testing done:
- omap3-beagle: boot + suspend/resume (ret + off)
- omap4-panda-es: boot + suspend/resume
-
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.
All information can be reconstructed by already known runtime
information.
As we now use some functions that were previously only used from __init
context,
Hi Brian, Ezequiel Garcia,
Some replies to your queries...
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Wed, Oct 30, 2013 at 06:53:07AM -0300, Ezequiel Garcia wrote:
[...]
I do have one curiosity here: omap2.c looks like it's essentially
defaulting to the NAND_OMAP_POLLED
From: Brian Norris [mailto:computersforpe...@gmail.com]
[...]
I agree with Ezequiel's thoughts, since the excessive amount of noise
in this patch series has delayed it significantly. But at this point,
I think it has stabilized; we have reviews from the DT folks (thanks
guys; please comment
Pekon,
Let me answer this one alone, given it's an important question.
On Wed, Oct 30, 2013 at 09:18:53PM +, Gupta, Pekon wrote:
I'm not sure, of course, but I don't see why not. It's more likely to
break for x16 than it is for x8.
Another question here is ..
The above patch
27 matches
Mail list logo
