Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Thu, May 13, 2010 at 12:16:16PM +0530, Hemanth V wrote:
>> ----- 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.
>>
>
> Realistically, what are the options though? The only sane solution is to
> hook it to a GPIO pin, isn't it?
>

One option I could think of is that output could be configured directly as
an interrupt line, rather than a gpio based interrupt. Yes, probably
gpio would be the most used option, but it would be good to make the driver
generic





--
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

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux