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 01:34:49PM +0530, Hemanth V wrote:
> > 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
> 

I'd wait till we have users for such setup.

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux