|
|
|
hardware hardware irq debouncing support
|
|
|
A flag will never be able to convey some important parameters like how long to debounce. But how important *is* that detail to most drivers? �In practice. I suspect they pick numbers today since they have to debounce with software timers, which require numbers. I think it's very important to drivers that have to deal with mechanical buttons and switches. In many cases, only the board code knows what kind of switch is hooked up to the interrupt, so the driver just passes on that information from the platform data. If the platform setup code knows the hardware debounce will be requested, it can adjust its platform_data debounce parameter accordingly. - Dave
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
hardware hardware irq debouncing support
|
|
|
I think it's very important to drivers that have to deal with mechanical buttons and switches. In many cases, only the board code knows what kind of switch is hooked up to the interrupt, so the driver just passes on that information from the platform data. If the platform setup code knows the hardware debounce will be requested, it can adjust its platform_data debounce parameter accordingly. I guess it could, but why would it do that? The debounce delay shouldn't depend on the mechanism used to implement it, should it? Or are you thinking about compensating for any delays introduced by IRQF_DEBOUNCE? Haavard
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
hardware hardware irq debouncing support
|
|
|
I just want a mechanism where you'll end up with the same behaviour regardless of what the hardware supports, at the cost of a timer if the hardware doesn't support the requested debounce delay. As an added benefit, this would eliminate the need for drivers to set up their own debounce timers. It would also make such more powerful hardware features easier to utilize from generic drivers, wouldn't it? But you've convinced me that your IRQF_DEBOUNCE hint might be useful too. Just for the record ... I'm withdrawing this proposal, in the sense that I won't be pursuing it any further. �A lighter weight solution is enough for now. I think the _frame_work we discussed
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
Favoured: 0
