> 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
