Hi Dmitry, On 11/12/2010 6:27 AM, Dmitry Torokhov wrote: > On Thu, Nov 11, 2010 at 05:30:21PM +0530, Trilok Soni wrote: >> Hi Dmitry, >> >> On 11/11/2010 12:51 PM, Dmitry Torokhov wrote: >>> Hi Trilkok, >>> >>> On Wed, Nov 10, 2010 at 06:17:59PM +0530, Trilok Soni wrote: >>>> Add support for PMIC8058 power key driven over dedicated KYPD_PWR_N >>>> pin. It allows the user to specify the amount of time by which the >>>> power key reporting can be delayed. >>>> >>> >>> Why do we need to delay KEY_POWER reporting? Do we need to use high >>> resolution timers or regular timers would do as well? KEY_END >>> appears to be abused (you don't want to move your cursor to the end >>> of line, do you?). Also I wonder if header file should reside in >>> linux/mfd with the rest of pmic8058 components. >> >> Most of the time Mobile devices come with single physical key for >> POWER, which if pressed for less than 500ms (configurable) then it >> will only report KEY_END (which say locks the screen on mobile) and if >> it pressed more than 500ms then it will also report KEY_POWER event >> too, which will say display menu on your mobile for asking you to >> suspend/switch off/etc, operations. >> > > I see,. If you would have used KEY_SCREENLOCK iinstead of KEY_END I > would likely not ask this question ;) > KEY_SCRENNLOCK looks good, let me analyze the impact on userspace framework which I have. I will come back on this in a day. >> For the timers I can move from hrtimers to regular timers. >> >> For the header file, I can move them to include/linux/mfd too. No >> problem on that. >> > > I am not even sure we need to keep them in separate header files, but it > is up to you. Do you suggest that all the MFD sub-devices's platform data structures should come from single header file? ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
