On Thu, May 13, 2010 at 12:16:16PM +0530, Hemanth V wrote: > ----- Original Message ----- From: "Christoph Fritz" > <[email protected]> > To: "Dmitry Torokhov" <[email protected]> > Cc: "Jonathan Cameron" <[email protected]>; "Datta, Shubhrajyoti" > <[email protected]>; <[email protected]>; > <[email protected]> > 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? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
