On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho coe...@ti.com wrote:
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat
On 15/06/2013, at 00:00, Grant Likely grant.lik...@linaro.org wrote:
On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi,
On Sunday 19 of May 2013 00:56:30 Tomasz Figa wrote:
Some drivers might rely on availability of trigger flags in IRQ
resource, for example
of 0 meant that.
So thanks a lot for doing this!
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 IRQ_TYPE_LEVEL_LOW; /* GPIO 176*/
+ reg-io-width = 4;
+ };
};
i2c3 {
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
___
devicetree-discuss mailing
On 06/06/2013 01:26 AM, Grant Likely wrote:
On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
On 04/09/2013 12:05 AM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
This means that drivers that need the IRQ type
On 06/06/2013 01:34 AM, Grant Likely wrote:
On Fri, 5 Apr 2013 09:48:08 +0200, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
[...]
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
On Fri, May 31, 2013 at 4:48 PM, Dan Murphy dmur...@ti.com wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
On 05/27/2013 10:40 AM, Benoit Cousson wrote:
Hi Javier,
Hi Benoit,
On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote:
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti
On 05/27/2013 10:54 AM, Benoit Cousson wrote:
On 05/27/2013 10:50 AM, Javier Martinez Canillas wrote:
On 05/27/2013 10:40 AM, Benoit Cousson wrote:
Hi Javier,
Hi Benoit,
On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote:
The IGEP COM Module has an 512MB NAND flash memory.
Add
On Fri, May 10, 2013 at 9:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Benoit
The IGEPv2 board has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Benoit,
This patch depends on a previous posted patch:
[PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 50
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- I just realized that sent a wrong version of the patch, sorry for the noise
arch/arm
On Wed, Apr 17, 2013 at 6:32 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC
by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti
On Sat, Apr 13, 2013 at 3:21 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify
On 04/18/2013 12:33 AM, Jon Hunter wrote:
On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote:
On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
On 04/09/2013 12:16 AM, Stephen Warren wrote:
On 04/08/2013 04:05 PM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According
On 04/17/2013 11:40 AM, Lars Poeschel wrote:
Hi Javier!
On Thursday 14 March 2013 at 22:54:11, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying around in this thread that I missed it :-)
Sorry about that...
No problem.
I was trying to see if we could find a common
On 04/17/2013 03:48 PM, Jon Hunter wrote:
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
Yes, in fact I just realized that for_each_node_by_name() expand to:
#define for_each_node_by_name(dn, name) \
for (dn = of_find_node_by_name(NULL, name); dn
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying
On Wed, Apr 17, 2013 at 3:52 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
There are so many patches flying
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas
nodes fails, this shouldn't make
the whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Reported-by: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2
...@lemonage.de
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous
If any of the GPMC child nodes fails, this shouldn't make the
whole gpmc_probe_dt() function to fail. It is better to just
WARN and allow other devices probe function to succeed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1 (suggested by Jon Hunter
On 04/17/2013 11:27 PM, Jon Hunter wrote:
On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search
Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 17 Apr 2013 02:03:08 +0200
Subject: [PATCH 1/1] gpio/omap: add custom xlate function handler
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 29 -
1 files
On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
Hi Linus, thanks a lot
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I
On Sat, Apr 13, 2013 at 8:59 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Yes, my last approach to solve the IRQ flags not saved
this is that it breaks the
I'm not sure I understand this paragraph; what is it in the line above.
If it is this patch, then should breaks be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernelm=136334655902407w=2
which is stating
Hello,
This is the second attempt to solve the issue that IRQ flags when
defined using Device Trees, are not passed to drivers that try
to obtain them from a IORESOURCE_IRQ struct resource.
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells
by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti
an IORESOURCE_IRQ
will not be able to get it.
So, is more safe to fallback and query this information from the irq
chip directly if it was not found on the struct resource.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/net/ethernet/smsc/smsc911x.c |4
On 04/12/2013 11:56 PM, Stephen Warren wrote:
On 04/12/2013 12:05 PM, Javier Martinez Canillas wrote:
...
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
diff --git a/include/linux/irq.h b/include/linux/irq.h
+static inline u32
by using irq_get_irq_data(irq) and
irqd_get_trigger_type(irq_data) but this will unnecessary expose
irq_data to callers and also is more error prone.
So, is better to add an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti
understand this paragraph; what is it in the line above.
If it is this patch, then should breaks be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernelm=136334655902407w=2
which is stating a question to grand, and contains the below
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote:
On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
On 04/09/2013 12:16 AM, Stephen Warren wrote:
On 04/08/2013 04:05 PM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According
On Tue, Apr 9, 2013 at 10:26 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote:
On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
On 04/09/2013 12:16 AM, Stephen Warren wrote:
On 04/08/2013 04:05 PM, Rob
On 04/09/2013 12:05 AM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed
On 04/09/2013 12:16 AM, Stephen Warren wrote:
On 04/08/2013 04:05 PM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Hi Javier
On Sat, 2013-03-30 at 14:18 +0100, Javier Martinez Canillas wrote:
A call to gpio_request() to enable the GPIO bank is needed before
using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
On Sat, Mar 30, 2013 at 9:21 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:
This patch sets gpio #interrupt-cells from a falsely acquired '1' to '2'
referring to Documentation/devicetree/bindings/gpio/gpio-omap.txt:
The first cell is the GPIO number.
The second cell is used
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move
On 03/26/2013 03:29 PM, Benoit Cousson wrote:
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation
On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar anilk...@gmail.com wrote:
Hi,
I am getting kernel uImage build issue on omap2+ log[1]
Taken kernel branch for_3.10/dts from
https://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Taking reference from
:01 AM, Javier Martinez Canillas wrote:
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an interrupt.
That seems wrong; the GPIO/IRQ driver
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller
;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent
or otherwise gpmc_probe_nor_child() would have
returned before.
This means that if of_platform_device_create() fails, 0 will be returned
to the caller instead of an appropriate error code.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c |1
Hello Jon,
As discussed before [1], this patch-set adds DT support for ethernet
controllers connected to a TI GPMC by making gpmc_probe_nor_child()
a generic function and reusing it to initialize ethernet child
devices nodes too. It also adds documentation about the DT binding.
The patch-set is
controllers need a similar
setup so by making this function generic it can be used for those too.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2
device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644
the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices
On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices
device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- Improve the DT binding documentation explaining that even when the GPMC
maximum bus address width is 16-bit, it supports devices with 32-bit
registers address width and the device
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices
device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- remove optional #address-cells and #size-cells since are not relevant for
ethernet chips; suggested by Jon Hunter.
Changes since v1:
- Improve the DT binding documentation explaining
On Thu, Mar 14, 2013 at 10:29 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote:
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
Besides being used
On Wed, Mar 13, 2013 at 5:41 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26
On 03/11/2013 06:13 PM, Jon Hunter wrote:
Hi Jon, thanks a lot for your feedback.
On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices
On 03/11/2013 07:11 PM, Jon Hunter wrote:
On 03/11/2013 12:57 PM, Javier Martinez Canillas wrote:
On 03/11/2013 06:13 PM, Jon Hunter wrote:
Hi Jon, thanks a lot for your feedback.
On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external
is made using the GPMC DT ranges property.
But also a explicit call to gpmc_cs_request() is needed.
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon
On Fri, Mar 8, 2013 at 5:58 PM, Jon Hunter jon-hun...@ti.com wrote:
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/gpio/gpio-omap.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio
to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
Hi Jon,
NOTE: I'm changing $subject to something more relevant to stop adding
noise on the original thread.
On Thu, Feb 28, 2013 at 9:49 PM, Jon Hunter jon-hun...@ti.com wrote:
On 02/28/2013 06:17 AM, Javier Martinez Canillas wrote:
On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter jon-hun
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
matthias@gmail.com
wrote:
Hi Benoit
On Thu, Feb 28, 2013 at 12:16 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 09:57 PM, Javier Martinez Canillas wrote:
[snip]
Something like that would definitely solve the GPIO request issue but
we still have the issue that the current OMAP GPIO controller binding
does not support
On Wed, Feb 27, 2013 at 6:47 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 08:33 PM, Javier Martinez Canillas wrote:
...
Yes, I realized that requesting the gpio was necessary so what I did
is to use the regulator-fixed optional property gpio and define
the GPIO used as an IRQ
On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote:
On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 06:13 PM, Stephen Warren wrote:
On 02/26/2013 04:45 PM, Jon Hunter wrote
On Fri, Feb 24, 2012 at 4:30 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/22/2012 7:29 PM, Stephen Warren wrote:
Rob Herring wrote at Wednesday, February 22, 2012 10:23 AM:
On 02/22/2012 08:31 AM, Cousson, Benoit wrote:
On 2/22/2012 3:23 PM, Rob Herring wrote:
On 02/15/2012 10:04 AM,
On Tue, Feb 26, 2013 at 11:40 PM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC
On Wed, Feb 27, 2013 at 12:08 AM, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC
:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
[snip]
I was wondering if the level/edge settings for gpios is working on
OMAP.
I'm adding DT support for an SMSC911x ethernet chip connected to the
GPMC for an OMAP3 SoC based board
On 02/18/2013 02:51 PM, Grant Likely wrote:
On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas
On Sat, Feb 16, 2013 at 2:09 PM, Anil Kumar anilkumar...@gmail.com wrote:
Hi Florian,
On Mon, Jan 28, 2013 at 11:24 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas wrote:
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier
On Mon, Feb 11, 2013 at 11:30 AM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
I have a few comments on the binding and the way it's parsed.
On Sat, Feb 09, 2013 at 08:44:27PM +, Javier Martinez Canillas wrote:
This patch adds a helper function to parse a device node that
contains all
On Mon, Feb 11, 2013 at 12:24 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Feb 11, 2013 at 11:33:19AM +0100, Javier Martinez Canillas wrote:
On Mon, Feb 11, 2013 at 9:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Feb 10, 2013 at 12:35:43PM +0100, Javier Martinez Canillas
On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
I knew this would be controversial and that's why I didn't mean it to be a
patch
but a RFC :)
The problem basically is that you
This patch adds a General-Purpose Memory Controller (GPMC)
device node to be used for OMAP3 based SoC boards.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
IGEPv2 boards has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip so the GPMC
driver will call the gpmc-smsc911x setup code.
Signed-off-by: Javier Martinez Canillas javier.marti
to be defined
as an GPMC child node an call its corresponding setup function.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach
If no pinctrl is available just report a warning since
it may not needed in some cases (e.g: non-DT kernels).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/net/ethernet/smsc/smsc911x.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions
This patch adds a helper function to parse a device node that
contains all the properties needed to initialize an smsc911x
device connected to an OMAP processor through OMAP's GPMC.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/net/gpmc
Hello,
This is an RFC to add Device Tree support for SMSC LAN chips connected
to OMAP processors though its General-Purpose Memory Controller.
The patch-set is composed of the following patches:
[PATCH RFC 1/7] platform: add a device node
[PATCH RFC 2/7] net: smsc911x: add pinctrl support
The smsc911x driver needs the GPMC smsc911x associated device
node to set the OMAP mux pins using the pinctrl framework.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/gpmc-smsc911x.c |5 -
arch/arm/mach-omap2/gpmc-smsc911x.h |1 +
2
to the platform device registration function.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-imx/devices/platform-gpio-mxc.c |2 +-
arch/arm/mach-imx/devices/platform-imx-dma.c |4 ++--
arch/arm/mach-imx/mach-armadillo5x0.c |2
Hi Greg,
Thanks a lot for your feedback.
On 02/10/2013 02:02 AM, Greg Kroah-Hartman wrote:
On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote:
When using Device Trees, it is necessary to associate a
device node with a platform device.
Usually this device node has
On Tue, Feb 5, 2013 at 6:23 PM, Florian Vaussard
florian.vauss...@epfl.ch wrote:
Hi Javier,
Hi Florian,
On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote:
[...]
Yes, I saw on the list that Tony asked you too extend the GPMC DT
support. Flash support is on my TODO list too but I
for Daniel's patches
to hit mainline before sending the RFC. So please feel free to add:
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
1 - 100 of 116 matches
Mail list logo
