----- Original Message -----
From: "Christoph Fritz" <chf.fritz@xxxxxxxxxxxxxx>
To: "Dmitry Torokhov" <dmitry.torokhov@xxxxxxxxx>
Cc: "Jonathan Cameron" <jic23@xxxxxxxxx>; "Datta, Shubhrajyoti"
<shubhrajyoti@xxxxxx>; <linux-input@xxxxxxxxxxxxxxx>;
<linux-omap@xxxxxxxxxxxxxxx>
Sent: Thursday, May 13, 2010 1:38 AM
Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote:
On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote:
> Hi,
>
> I was wondering if you could provide a bit more detail on what this
> driver is actually doing? My appologies if I have missed a
> previous explanation. If so, please add a Documentation file
> to explain what is going on.
>
> The driver you have here does virtually nothing itself. It takes
> both its source of interrupt and read function from platform
> data. Given the value is always 0 or 1, I'm guessing you are
> simply reading a gpio pin. That makes this effectively a button
> and doesn't require any specific code. The fact it is a
> proximity sensor isn't relevant to anything other than perhaps
> the name.
Excellent point. Maybe it should simply use gpio_keys driver with
SW_FRONT_PROXIMITY code.
I had a look into the datasheet, this SFH 7741 has one Schmitt trigger
output: So yes, it's a "key" even without chatter.
Output being configured as GPIO is specific to OMAP4 board, SFH7741 doesnot
really
mandate this. The idea behind this driver is to provide a generic interface
and
hooks for platform specific configuration.
Will using gpio_keys make this very specific to platform configuration.
Thanks
Hemanth
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html