Thread (7 messages) flat view 7 messages, 5 authors, 2012-05-04

Re: qt1070: Why IRQF_TRIGGER_NONE?

From: javier Martin <hidden>
Date: 2012-05-04 07:06:17

Hi all,
thank you for your comments.

On 4 May 2012 04:07, Shen, Voice [off-list ref] wrote:
Hi Jean,
 Thank you for your information. Although the irq_flag can not be added into "struct i2c_board_info" till now, I will try to find other solution.

 Thanks again.

Hi Javier,
 As to the IRQ flag depends on SOC. We try to find other solution. Please describe you issue in detail. And what's the mode does your SOC support.
As I stated, with the current 'IRQF_TRIGGER_NONE' flag, this driver
doesn't work in i.MX27. Furthermore, I don't think it works on any
platform since as you previously pointed according to the datasheet of
qt1070, we can use either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW.
But I don't know what is the sense of using 'IRQF_TRIGGER_NONE' here.

My SoC, an i.MX27, theoretically supports both RQF_TRIGGER_FALLING and
IRQF_TRIGGER_LOW but I've only tested the former.

If we take a look at a similar device, a pca953x they simply use the
following flags: (IRQF_TRIGGER_LOW | IRQF_ONESHOT)
http://lxr.linux.no/#linux+v3.3.4/drivers/gpio/gpio-pca953x.c#L495

We could do the same here. It's true there can be SoC's which doesn't
support IRQF_TRIGGER_LOW flag, but if this is the case it means they
don't support this HW feature then. So you are not breaking anything.
Best Regards,
Voice Shen
-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Thursday, May 03, 2012 14:15 申波
To: Shen, Voice
Cc: Wu, Josh; javier Martin; linux-input@vger.kernel.org; Wolfram Sang; Axel Lin; Dmitry Torokhov
Subject: Re: qt1070: Why IRQF_TRIGGER_NONE?

On Thu, 3 May 2012 05:15:14 +0000, Shen, Voice wrote:
quoted
Hi All,
  Some information as following,

  According to the datasheet of qt1070, we can use IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW (I think this is the best) for IRQ flag. However, the IRQ line is a GPIO of a SOC. Some SOC can detect the level change of the GPIO, while can not distinguish the falling or rising. So, the IRQ flag depends on the trigger mode of GPIO line.

  Maybe use the "flags" element in "struct i2c_board_info" to pass the IRQ flag, or add another element named "irqflags" into "struct i2c_board_info". I think this will be better, but I am not sure whether this is a good solution.
i2c_board_info.flags is for I2C client flags, please do not abuse it
for IRQ information.

I have no objection to an irq_flag member being added, however I
remember past discussions where people argued whether it was the right
thing to do or whether the IRQ mode was best set by platform
initialization code. Part of that discussion was archived here:
http://marc.info/?t=128743170300002&r=1&w=2
Said discussion did not result in any code being merged as I don't
think we came to an agreement. Feel free to restart the discussion with
the interested people.

--
Jean Delvare


-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help