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
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-igep0030.dts | 43
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0 deletions(-)
create mode
ap3-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
+ * Copyright (C) 2012 Enric Balletbo i Serra
+ *
+ * This program i
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
Acked-by: Matthias Brugger
---
Changes since v1:
- Use default-state = "on" inste
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 SoCs:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Matthias Brugger
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0
On Wed, Mar 13, 2013 at 5:41 PM, Benoit Cousson 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 wrote:
>>> Hi Matthias,
>>>
>>>
>>> On 2/15/2013 10:35 AM,
On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar 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
> https://kernel.googlesource.com/
[cc'ing Benoit Cousson (OMAP DT maintainer)]
On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
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 97238b35d5bb
>>
On Tue, Jul 16, 2013 at 8:57 AM, Ferruh Yigit 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
On Thu, Aug 29, 2013 at 12:06 PM, Benoit Cousson 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,
On Sun, Sep 15, 2013 at 10:44 PM, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.
>
> Signed-off-by: Sebastian Reichel
> ---
> Documentation/devicetree/bindings/hsi/omap_ssi.txt | 73
> ++
> arch/arm/boot/dts/omap3-n900.dts
On Mon, Sep 16, 2013 at 5:01 PM, Sebastian Reichel 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 inste
On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár 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 +0200, Pali Rohá
On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek 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 isola
On Wed, Sep 18, 2013 at 1:50 AM, Tony Lindgren wrote:
> * Aaro Koskinen [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 v2?
>>
>> I don'
On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek 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,
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
>>> wrote:
>>>> On Mon, Jul 29, 2013 at 6:36 AM, Lin
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 HA
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 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 co
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,
>>> s
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
>> wrote:
>>> On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
>>
I don't see how sharing works here, or how another user, i.e. another o
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 {
On 08/29/2013 09:26 PM, Linus Walleij wrote:
> On Tue, Aug 27, 2013 at 10:17 PM, Stephen Warren
> 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 as
>>> ort
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 whe
On 09/27/2013 08:08 PM, Kevin Hilman wrote:
> Javier Martinez Canillas 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
&g
setup on the GPIO/IRQ chip driver when a call to
request_irq() is made.
Signed-off-by: Javier Martinez Canillas
---
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"
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/23/2013 06:45 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [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,
>> ret
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
>
On 09/23/2013 10:15 PM, Linus Walleij wrote:
> On Sun, Sep 22, 2013 at 4:40 PM, 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
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 [130923 10:09]:
>>> On 09/23/2013 06:45 PM, Tony Lindgren wrote:
>>>> Hmm does this still work for legacy platform data
nd set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
Signed-off-by: Javier Martinez Canillas
---
Tested on a OMAP3 DM3730 board with both legacy and DT based booting.
Changes since v1:
- Simplify patch description as suggested by Stephen Warren.
-
On 09/24/2013 05:40 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [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 an interru
controller's irq_chip driver when
a caller requests an interrupt line.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpio/gpio-omap.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio
nd set its 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
---
drivers/gpio/g
nd set its 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
---
drivers/gpio/g
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
---
MAINTAINERS |8
1 files changed, 8
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
&g
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
Acked-by: Matthias Brugger
Tested-by: Enric Balletbo i Serra
---
Changes since v1:
- Use default
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Matthias Brugger
Tested-by: Enric Balletbo i Serra
---
Changes since v2:
- Associate uart3_pins in uart3 device node.
- Remove
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
Acked
On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas
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 from
On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
> On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
> wrote:
>> commit a99d76f leds: leds-gpio: use gpio_request_one
>>
>> changed the leds-gpio driver to use gpio_request_one() instead
>> of gpio_req
xplicitly.
Signed-off-by: Javier Martinez Canillas
---
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
r
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
---
arch/mips/cavium-octeon/octeon-irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips
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
---
kernel/irq/irqdomain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/irqdomain.c b
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
---
drivers/mfd/twl4030-irq.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c
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
---
drivers/mfd/stmpe.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd
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
---
include/linux/irq.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
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
---
arch/arm/plat-orion/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-orion/gpio.c b
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 ca
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
---
drivers/gpio/gpio-mvebu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b
On 15/06/2013, at 00:00, Grant Likely wrote:
> On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa 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 to configure the hardware for pa
tthias Kaehlcke
> ---
Acked-by: Javier Martinez Canillas
--
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://www.tux.org/lkml/
sp4 - Core driver for Cypress TMA4XX touchscreen 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
> drivers/input/touchscre
On Fri, May 31, 2013 at 4:48 PM, Dan Murphy 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
> the res
On 06/18/2013 12:29 AM, Grant Likely wrote:
> On Fri, Jun 14, 2013 at 5:40 PM, Javier Martinez Canillas
> 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
On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho 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 edge tri
tthias Kaehlcke
> Acked-by: Javier Martinez Canillas
> Acked-by: Ferruh Yigit
>
> ---
> drivers/input/touchscreen/cyttsp_core.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/cyttsp_core.h
> b/drivers/input/touchscr
rruh works for Cypress, we may change the driver
status from Maintained to Supported.
Signed-off-by: Javier Martinez Canillas
---
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 of
Cypress instea
rruh works for Cypress, we may change the driver
status from Maintained to Supported.
Signed-off-by: Javier Martinez Canillas
---
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 of
Cypress instea
On 07/31/2013 01:44 AM, Linus Walleij wrote:
> On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely wrote:
>> On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij
>> wrote:
>>> To solve this dilemma, perform an interrupt consistency check
>>> when adding a GPIO chip: if the chip is both gpio-controller and
>
On Tue, Aug 6, 2013 at 1:02 AM, Rohit Vaswani 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
> ---
> arch/arm/boot/dts/Makefile|
#gpio-cells = <2>;
> interrupt-controller;
> - #interrupt-cells = <1>;
> + #interrupt-cells = <2>;
> reg = <0x481ae000 0x1000>;
> interrup
On Sat, Aug 10, 2013 at 10:29 PM, Jiri Kosina wrote:
> On Sat, 10 Aug 2013, Pavel Machek wrote:
>
>> [I wonder if this is clean-enough cause for "trivial in resubmit
>> mode?]
>
> On Sat, 10 Aug 2013, Belisko Marek wrote:
>
>> Same for gta04 (omap3 based device) [1].
>> It was send upstream 2 time
Hi Pavel,
some minor comments about your patch below
On Sat, Jul 13, 2013 at 2:17 PM, Pavel Machek wrote:
>
> This adds device tree with neccessary support to boot with functional
> video (on both emulator and real N900 device).
>
> Signed-off-by: Pavel Machek
>
> ---
>
> From v1: Aaro wants ju
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit wrote:
> Hi Matthias,
>
>
> On 2/15/2013 10:35 AM, Matthias Brugger wrote:
>>
>> 2013/1/26 Javier Martinez Canillas :
>>>
>>> On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
>>>
>>
cked-by: Javier Martinez Canillas
> ---
> 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 8e60437..97ba891 1006
goto out;
> - }
> + error = _cyttsp_hndshk(ts, ts->xy_data.hst_mode);
> + if (error)
> + goto out;
>
> if (unlikely(ts->state == CY_IDLE_STATE))
> goto out;
> --
> 1.7.9.5
>
> This message and an
On Fri, Sep 14, 2012 at 8:46 PM, Henrik Rydberg 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 integrate wit
On Tue, Aug 7, 2012 at 3:09 PM, Ferruh Yigit wrote:
> From: Ferruh YIGIT
>
> 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 modules.
> Core driver:
On Wed, Dec 12, 2012 at 11:11 AM, Benoit Cousson 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
>> wrote:
>>> IGEP technology devices are TI OMAP3 SoC based industrial embed
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
---
arch/arm/mach-omap2/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b
Hello Sakari,
On 07/20/2016 09:03 AM, Sakari Ailus wrote:
> Hi Javier,
>
> Thanks for the patch!
>
Thanks for your feedback.
> On Thu, Jul 14, 2016 at 11:09:34AM -0400, Javier Martinez Canillas wrote:
>> If the the VIDIOC_QBUF ioctl fails due a wrong dmabuf length,
>
Hello Sakari,
On 07/20/2016 09:20 AM, Sakari Ailus wrote:
> Hi Javier,
>
> On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
>> The buffer planes' dma-buf are currently mapped when buffers are queued
>> from userspace but it's more app
Hello Hans,
On 07/20/2016 10:12 AM, Hans Verkuil wrote:
> On 07/20/2016 04:06 PM, Javier Martinez Canillas wrote:
>> Hello Sakari,
>>
>> On 07/20/2016 09:20 AM, Sakari Ailus wrote:
>>> Hi Javier,
>>>
>>> On Fri, Jul 15, 2016 at 12:26:06PM -0400,
ane 1, minimum
length 410880
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Use %u instead of %d (Sakari Ailus)
- Include min_length (Sakari Ailus)
drivers/media/v4l2-core/videobuf2-core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2
recover, since it may had dropped the
buffer(s) already when it knows that the dma-buf mapping failed.
So remove the TODO instead and change the comment to explain this.
Suggested-by: Hans Verkuil
Signed-off-by: Javier Martinez Canillas
---
Hello,
This patch was suggested by Hans as a feedback
ng is done.
Decoupling the buffer dequeue from the dma-buf unmapping has also the side
effect of making possible to add dma-buf fence support in the future since
the buffer could be dequeued even before the driver has finished using it.
Signed-off-by: Javier Martinez Canillas
---
Hello,
I'
Hello Sakari,
On 07/20/2016 03:52 PM, Sakari Ailus wrote:
> On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
>> If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
>> useful to get the invalid and minimum lengths as a debug info.
>
Hello Sakari,
On 07/20/2016 07:08 PM, Sakari Ailus wrote:
> Hi Javier,
>
> On Wed, Jul 20, 2016 at 06:56:52PM -0400, Javier Martinez Canillas wrote:
>> Hello Sakari,
>>
>> On 07/20/2016 03:52 PM, Sakari Ailus wrote:
>>> On Wed, Jul 20, 2016 at 12:07:55PM -
Martinez Canillas
---
drivers/hid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 08f53c7fd513..386f31481c06 100644
*** a/drivers/hid/hid-core.c
--- b/drivers/hid/hid-core.c
***
*** 2480,2486
Martinez Canillas
---
Changes in v2:
- Post correct patch since v1 got mangled by the MTA.
drivers/hid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 08f53c7fd513..386f31481c06 100644
--- a/drivers/hid/hid
Hello,
On 07/21/2016 11:20 AM, Javier Martinez Canillas wrote:
> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
> built-in or as a module, use that macro instead of open coding the same.
>
> Using the macro makes the code more readable by helping abstra
Martinez Canillas
---
drivers/i2c/busses/i2c-i801.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 68cec6128ac0..5ef9b733d153 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c
or -EPROTOOPT
>
>> EC_RES_INVALID_HEADER
>
> -EPROTO or -EBADR or -EBADE
>
> Doesn't look that bad to me. Also, the raw error could still be logged,
> for example with dev_dbg().
>
Yes, I think that adding a dev_dbg() with the real EC error code should
be enough, that's basically what drivers do since they can't propagate
the EC error to higher layers anyways.
> Guenter
>
>>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Hello Brian,
On 06/20/2016 02:10 PM, Brian Norris wrote:
> Hi,
>
> On Mon, Jun 20, 2016 at 10:44:55AM -0700, Brian Norris wrote:
>> On Mon, Jun 20, 2016 at 09:46:57AM -0400, Javier Martinez Canillas wrote:
>>> On 06/18/2016 01:09 PM, Guenter Roeck wrote:
>>>>
Hello Kalle,
On 06/10/2016 03:54 PM, Kalle Valo wrote:
> Javier Martinez Canillas writes:
>
>>> This patch (2/3) is only for code rearrangement and adds an
>>> unnecessary wrapper function. We can simply drop the patch.
>>
>> Agreed.
>>
>> K
This patch fixes the following DTC warnings for many boards:
"Node /gpio_keys/button0@10 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-overo-alto35-common.dtsi | 2 +-
arch/arm/boot/dts/omap3-overo-chestnut43-commo
Hello Tony,
This is yet another series with fixes for DTC warnings caused by mismatches
between device nodes' unit names and reg properties.
The patches should not cause a functional change but were only build tested.
Best regards,
Javier
Javier Martinez Canillas (10):
ARM: dts:
This patch fixes the following DTC warnings for many boards:
"Node /fixedregulator@0 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/am335x-baltos.dtsi | 4 ++--
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 +-
arch/arm/boot/
: remove unneded unit names in
display nodes")
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi
b/arch/arm/boot/dts/omap3-overo-c
This patch fixes the following DTC warnings for many boards:
"Node /fixedregulator@0 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/da850-evm.dts | 2 +-
arch/arm/boot/dts/dm8148-evm.dts | 2 +-
arch/arm/boot/dts/dm8148-t4
This patch fixes the following DTC warnings for many boards:
"Node /gpio_keys/button0@10 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/am335x-evm.dts | 6 +++---
arch/arm/boot/dts/am335x-evmsk.dts | 10 +-
arch/ar
This patch fixes the following DTC warnings for many boards:
"Node /matrix_keypad@0 has a unit name, but no reg property"
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
arch/arm/boot/dts/am437x-
1 - 100 of 3499 matches
Mail list logo
