[PATCH] gpio: omap: fix debounce time calculation

[santosh.shilimkar@oracle.com (santosh shilimkar)]

On 11/12/2015 11:33 AM, Felipe Balbi wrote:
>
> Hi,
>
> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>> On 11/12/2015 08:09 PM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>>> On 11/12/2015 07:50 PM, Felipe Balbi wrote:
>>>>> According to TRM, debounce is measured in periods of
>>>>> the functional clock of the GPIO IP. This means that
>>>>
>>>>
>>>> What TRM? link pls.
>>>>
>>>> http://www.ti.com/lit/ug/spruhl7d/spruhl7d.pdf
>>>>
>>>> 28.4.1.24 GPIO_DEBOUNCINGTIME Register (offset = 154h) [reset = 0h]
>>>>
>>>> The GPIO_DEBOUNCINGTIME register controls debouncing time (the value is
>>>> global for all ports). The debouncing cell is running with the
>>>> debouncing clock (32 kHz), this register represents the number of the
>>>> clock cycle(s) (31 s long) to be used.
>>>>
>>>> Debouncing Value in 31 microsecond steps.
>>>> Debouncing Value = (DEBOUNCETIME + 1) * 31 microseconds.
>>>
>>> DRA7xx:
>>>
>>> "
>>> 8-bit values specifying the debouncing time. It is n-
>>> periods of the muxed clock, which can come from either
>>> a true 32k oscillator/pad of from the system clock. It
>>> depends on which boot mode is selected. For more
>>> information see Chapter 32, Initialization.
>>> "
>>>
>>
>> See
>> http://www.ti.com/lit/ug/spruhz6d/spruhz6d.pdf
>> 27.4.3 General-Purpose Interface Clock Configuration
>> 27.4.3.1 Clocking
>>
>> This completely unclear. Sry, I think this patch can't be used as is,
>> first of all because of backward compatibility issues.
>
> yeah, might be. No issues, I'll just go dig older TRMs and trying to
> figure this one out. Meanwhile, let's let's keep it as is.
>
Just to be clear, being a common GPIO driver, it can't break
backward compatibility. So NAK for current patch.
If needed, please setup different debounce functions based
on GPIO IP numbers if it makes is efficient/accurate.

Regards,
Santosh