On Mon, 07 Mar 2016 11:13:55 -0300, Vinicius Costa Gomes wrote:
Sorry if I am a little too late.
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes:
Hi,Another issue of the current API is the confusion caused by
I would like to propose some changes to the public GPIO API.
Addressing major 2 issues which I faced while writing some code using
the API. And an third one, related to the consistency of the API.
1) the callback might need to know about the context: Let's say you
have a driver which sets a gpio callback. As soon as there is 2
instances of this driver, it won't be able to tell which instance
does that callback call belongs to (unless keeping book about which
gpio port/pin relates to which inner instance which is ugly)
2) 2+ different sub-system might need to set a callback: One
sub-system might be interested to get notified when pin X generated
an interrupt, when another would be interested by pin Y.
3) Currently, you can set either a callback for the whole port or
per-pin. The major difference is found in how callback is called:
-> port callback: the pin parameter of the callback is a bitfield,
each bit telling which pin generated and int.
-> pin callback: the pin parameter is the pin number and not anymore
a bit in a bitfield.
'gpio_port_enable_callback()' and 'gpio_pin_enable_callback()'.
With the changes proposed later in this thread, you could have a
'gpio_enable_callback(struct device *port, uint32_t pinmask)' (or something like it)
Consider there's a set/unset function in those changes, do we need to
enable? Can't we infer from the callbacks the user sets?