Enric and I have been mantained this machine and while we
are moving to device trees, it is good that people cc us
when reporting bugs or regression on the board file until
we have proper DT support.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
MAINTAINERS |8
1
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
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
.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..e2b9849
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
Changes since v1
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device tree allows to boot from an MMC/SD and are working all
the components that already have device tree support on OMAP3
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 93
On 12/03/2012 12:01 PM, Benoit Cousson wrote:
On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
Tested-by: Enric
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas
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 Fri, Sep 14, 2012 at 8:46 PM, Henrik Rydberg rydb...@euromail.se wrote:
Hi Ferruh,
This driver is for Cypress TrueTouch(tm) Standard Product controllers,
Generation4 devices.
This is second version of driver, code re-structured to match with
existing Generation3 driver code.
To
On Tue, Aug 7, 2012 at 3:09 PM, Ferruh Yigit f...@cypress.com wrote:
From: Ferruh YIGIT f...@cypress.com
This driver is for Cypress TrueTouch(tm) Standard Product controllers,
Generation4 devices.
Driver consist of four main modules:
Bus driver: Linux bus driver implementation, binds other
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patchset adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions
-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
I sent this patch before but then realized that I only cc'ed to linux-leds.
So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
reach a broader
On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit a99d76f leds: leds-gpio: use gpio_request_one
changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device trees allows to boot
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote:
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
IGEP technology devices are TI OMAP3 SoC based
or
directory
compilation terminated.
make[1]: *** [arch/arm/mach-omap2/common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/mach-omap2/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git
On Tue, Aug 6, 2013 at 1:02 AM, Rohit Vaswani rvasw...@codeaurora.org wrote:
This patch adds basic board support for MSM8974 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
Signed-off-by: Rohit Vaswani rvasw...@codeaurora.org
;
interrupts = 62;
};
--
1.7.10.4
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cc'ing Benoit Cousson (OMAP DT maintainer)]
On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-bone.dts between commit
for Cypress, we may change the driver
status from Maintained to Supported.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
Ferruh, please send your ack if you are willing to take over
maintainance of this driver.
Also, please confirm that you have been working on behalf
for Cypress, we may change the driver
status from Maintained to Supported.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
Ferruh, please send your ack if you are willing to take over
maintainance of this driver.
Also, please confirm that you have been working on behalf
On 09/10/2013 09:00 AM, Joel Fernandes wrote:
On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org
wrote:
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall
On 09/10/2013 10:47 AM, Lars Poeschel wrote:
On Tuesday 10 September 2013 17:19:24, Mark Brown wrote:
On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
On 09/04/2013 03:05 AM, Lars Poeschel wrote:
The driver that tries to use the GPIO requested by this patch before HAS
to
On 09/10/2013 05:00 PM, Joel Fernandes wrote:
On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
On 09/10/2013 09:00 AM, Joel Fernandes wrote:
On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant
On 09/10/2013 09:52 PM, Stephen Warren wrote:
On 09/10/2013 07:56 AM, Javier Martinez Canillas wrote:
...
The only thing that this patch tries to solve is when a driver expect to
request
a IRQ and it doesn't care if is a real IRQ line from an interrupt controller
or
a GPIO pin mapped
On 09/11/2013 12:34 AM, Stephen Warren wrote:
On 09/10/2013 03:37 PM, Mark Brown wrote:
On Tue, Sep 10, 2013 at 01:53:47PM -0600, Stephen Warren wrote:
Doesn't this patch call gpio_request() on the GPIO first, and
hence prevent the driver's own gpio_request() from succeeding,
since the GPIO
On 09/11/2013 05:30 PM, Alexander Holler wrote:
Am 22.08.2013 00:02, schrieb Linus Walleij:
On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
I don't see how sharing works here, or how another
On 09/12/2013 10:55 AM, Alexander Holler wrote:
Am 11.09.2013 19:42, schrieb Alexander Holler:
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115
On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote:
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org
wrote:
To solve this dilemma, perform an interrupt consistency check
when adding a GPIO chip: if
On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel s...@debian.org wrote:
Add SSI device tree data for OMAP34xx and Nokia N900.
Signed-off-by: Sebastian Reichel s...@debian.org
---
Documentation/devicetree/bindings/hsi/omap_ssi.txt | 73
++
On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel s...@debian.org wrote:
Hi,
Is the Synchronous Serial Interface (SSI) only supported by
OMAP34xx/OMAP35xx SoC and not by OMAP36xx/OMAP37xx SoC?
I'm asking this since if SSI is supported by both we should add the
device nodes in omap3.dtsi
On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár pali.ro...@gmail.com wrote:
On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 06:05:15PM
On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
So will you do that? Or it is needed to resend this one line
hunk again in new email again?
new patch, new email
Guys, WHY ARE YOU SO STUPID AND ARROGANT?
Sorry but, need to copy full isolated patch/hunk from
On Wed, Sep 18, 2013 at 1:50 AM, Tony Lindgren t...@atomide.com wrote:
* Aaro Koskinen aaro.koski...@iki.fi [130907 16:10]:
Hi,
On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote:
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-camera.c
[...]
Ping, can you review this patch
On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
So will you do that? Or it is needed to resend this one line
hunk again in new email again?
new patch, new email
Guys, WHY ARE YOU SO STUPID AND ARROGANT?
Sorry but, need to copy full isolated
On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown ne...@suse.de wrote:
On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart afenk...@gmail.com wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected
On Sat, Oct 19, 2013 at 1:14 AM, NeilBrown ne...@suse.de wrote:
On Fri, 18 Oct 2013 12:12:48 +0200 Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
On Fri, Oct 18, 2013 at 8:20 AM, NeilBrown ne...@suse.de wrote:
On Sat, 5 Oct 2013 13:17:09 +0200 Andreas Fenkart afenk...@gmail.com
Martinez Canillas javier.marti...@collabora.co.uk
Yours,
Linus Walleij
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Hi Kishon,
On Fri, Dec 6, 2013 at 1:06 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
device name of the controller had *.auto* in it.
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_desc_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/mips/cavium-octeon/octeon-irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_desc_get_irq_data(virq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
kernel/irq/irqdomain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/twl4030-irq.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/stmpe.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git
to callers.
It's better to have an irq_get_trigger_type() function to obtain
the edge/level flags for an IRQ.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
include/linux/irq.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/plat-orion/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Drivers that want to get the trigger edge/level type flags for a
given interrupt have to first call irq_get_irq_data(irq) to get
the struct irq_data and then irqd_get_trigger_type(irq_data) to
obtain the IRQ flags.
This is not only error prone but also unnecessary exposes the
struct irq_data to
Use irq_get_trigger_type() to get the IRQ trigger type flags
instead calling irqd_get_trigger_type(irq_get_irq_data(irq))
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-mvebu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
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
-by: Matthias Kaehlcke matth...@kaehlcke.net
---
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
devices
Input: cyttsp4 - I2C driver for Cypress TMA4XX touchscreen devices
Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices
For the whole series:
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
drivers/input/touchscreen/Kconfig | 30 +
drivers/input
On 06/18/2013 12:29 AM, Grant Likely wrote:
On Fri, Jun 14, 2013 at 5:40 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Drivers that want to get the trigger edge/level type flags for a
given interrupt have to first call irq_get_irq_data(irq) to get
the struct irq_data
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
catch, thanks for fixing it
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
drivers/input/touchscreen/cyttsp_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp_core.c
b/drivers/input/touchscreen/cyttsp_core.c
index
contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, Jul 16, 2013 at 8:57 AM, Ferruh Yigit f...@cypress.com wrote:
On 07/15/2013 12:41 AM, Javier Martinez Canillas wrote:
I haven't had time to work on this driver for a long time and
Ferruh has been doing a great job making it more generic,
adding support for new hardware and providing
On Thu, Aug 29, 2013 at 12:06 PM, Benoit Cousson bcous...@baylibre.com wrote:
Hi Felipe
On 27/08/2013 21:56, Felipe Balbi wrote:
Hi,
On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote:
On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote:
Hi,
On Tue, Aug 27, 2013 at
On 08/29/2013 09:26 PM, Linus Walleij wrote:
On Tue, Aug 27, 2013 at 10:17 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 08/26/2013 08:07 AM, Lars Poeschel wrote:
Currently the kernel is ambigously treating GPIOs and interrupts
from a GPIO controller: GPIOs and interrupts are treated
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
to
request_irq() is made.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hello,
This patch is an attempt to solve the long standing issue that we have been
discussing in thread:
[PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs [1]
The fix is just for OMAP
On 09/16/2013 07:09 PM, Stephen Warren wrote:
On 09/16/2013 10:03 AM, Lars Poeschel wrote:
On Monday 16 September 2013 13:43:50, Stephen Warren wrote:
On 09/10/2013 06:52 PM, Javier Martinez Canillas wrote:
On 09/11/2013 12:34 AM, Stephen Warren wrote:
On 09/10/2013 03:37 PM, Mark Brown wrote
On 09/23/2013 06:45 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130922 07:49]:
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -420,6 +420,29 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
int gpio,
return 0
On 09/23/2013 06:14 PM, Stephen Warren wrote:
On 09/22/2013 08:40 AM, Javier Martinez Canillas wrote:
To use a GPIO pin as an interrupt line, two previous configurations
have to be made:
a) Map the GPIO pin as an interrupt line into the Linux irq space
b) Enable the GPIO bank and configure
On 09/23/2013 10:15 PM, Linus Walleij wrote:
On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
To use a GPIO pin as an interrupt line, two previous configurations
have to be made:
a) Map the GPIO pin as an interrupt line into the Linux irq
On 09/24/2013 09:39 AM, Sricharan R wrote:
Hi,
On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130923 10:09]:
On 09/23/2013 06:45 PM, Tony Lindgren wrote:
Hmm does this still work for legacy platform data based
drivers
direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Tested on a OMAP3 DM3730 board with both legacy and DT based booting.
Changes since v1:
- Simplify patch description as suggested
On 09/24/2013 05:40 PM, Tony Lindgren wrote:
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 01:06]:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether
the controller's irq_chip driver when
a caller requests an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio
direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
On 09/27/2013 01:18 AM, Stephen Warren wrote:
On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote:
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also
On 09/27/2013 08:08 PM, Kevin Hilman wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always
MAX77802 is a PMIC that contains 10 high efficiency Buck regulators,
32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs,
a Real-Time-Clock (RTC) and a I2C interface to program the individual
regulators, clocks and the RTC.
This series are based on drivers added by Simon Glass to
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
(LDO) regulators. This patch adds support for all these regulators
found on the MAX77802 PMIC and is based on a driver added by Simon
Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti
The MAX7802 PMIC has a Real-Time-Clock (RTC) with two alarms.
This patch adds support for the RTC and is based on a driver
added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mfd/max77802.c | 3
-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 320 +
1 file changed, 320 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1c5b8f9
The MAX77802 PMIC has two 32.768kHz Buffered Clock Outputs with
Low Jitter Mode. This patch adds support for these two clocks.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
.../devicetree/bindings/clock/maxim,max77802.txt | 40
drivers/clk/Kconfig
, clocks outputs and the RTC.
This patch adds the core support for MAX77802 PMIC and is based
on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/mfd/max77802.txt | 88
Hello Krzystof,
Thanks a lot for your feedback.
On 06/09/2014 06:04 PM, Doug Anderson wrote:
Krzystof,
On Mon, Jun 9, 2014 at 3:16 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote:
MAX77802 is a PMIC that contains 10
Hello Krzysztof,
On 06/09/2014 12:22 PM, Krzysztof Kozlowski wrote:
On pon, 2014-06-09 at 11:37 +0200, Javier Martinez Canillas wrote:
Maxim MAX77802 is a power management chip that contains 10 high
efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
to power up application
Hello Mark,
Thanks a lot for your feedback.
On 06/09/2014 09:38 PM, Mark Brown wrote:
On Mon, Jun 09, 2014 at 11:37:47AM +0200, Javier Martinez Canillas wrote:
+case REGULATOR_MODE_STANDBY:/* switch off */
+if (id != MAX77802_LDO1 id != MAX77802_LDO20
Hello Mark,
On 06/09/2014 09:47 PM, Mark Brown wrote:
On Mon, Jun 09, 2014 at 11:37:46AM +0200, Javier Martinez Canillas wrote:
+Optional node:
+- voltage-regulators : The regulators of max77802 have to be instantiated
+ under subnode named voltage-regulators using the following format
Martinez Canillas wrote:
MAX77802 is a PMIC that contains 10 high efficiency Buck regulators,
32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs,
a Real-Time-Clock (RTC) and a I2C interface to program the individual
regulators, clocks and the RTC.
This series are based on drivers
Hello Roger,
What a great series!!
On Wed, Jun 11, 2014 at 10:56 AM, Roger Quadros rog...@ti.com wrote:
Hi,
This is a complete functional set to get the gpmc driver out of mach-omap2
and into drivers/memory. The DT binding remains the same except for the
following minor changes
I probably
CLK_SCLK_MAUDIO0, clock CLK_SCLK_MAUPCM0;
clock-names = pll_ref, pll_in, sclk_audio,
sclk_pcm_in;
};
--
1.7.9.5
--
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
Hello Roger,
On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
Hi Ezequiel,
On 05/21/2014 07:08 PM, Ezequiel Garcia wrote:
Hi Roger,
On 21 May 02:20 PM, Roger Quadros wrote:
For DT boot:
- The GPMC controller node should have a chip select (CS) node for each used
Hello Roger,
On Fri, May 23, 2014 at 10:16 AM, Roger Quadros rog...@ti.com wrote:
Ezequiel Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
On 22 May 01:51 PM, Javier Martinez Canillas wrote:
On Thu, May 22, 2014 at 10:12 AM, Roger Quadros rog...@ti.com wrote:
On 21 May 02:20 PM
this in the clock driver.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/clk/samsung/clk-exynos5420.c | 24
1 file changed, 24 insertions(+)
I tested your patch and it solves the issue for me, so feel free to add
Tested-by: Javier Martinez Canillas
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who
Hello Pantelis,
On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200
Hello Jhon,
On Wed, May 14, 2014 at 7:44 AM, John Syn john3...@gmail.com wrote:
On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
wrote:
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
wrote
1 - 100 of 6991 matches
Mail list logo
