Re: svn commit: r299563 - head/sys/dev/gpio
Ian Lepore (i...@freebsd.org) wrote: > On Thu, 2016-05-12 at 20:12 +, Oleksandr Tymoshenko wrote: > > Author: gonzo > > Date: Thu May 12 20:12:45 2016 > > New Revision: 299563 > > URL: https://svnweb.freebsd.org/changeset/base/299563 > > > > Log: > > Add gpiobus_release_pin function to release mapped pin > > > > Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. > > Without it it's impossible to properly release pin so if kernel > > module is reloaded it can't re-use pins again > > This reminds me that we (Michael Meloun & I) had talked on irc about > renaming gpiobus_map_pin() to gpiobus_acquire_pin() and adding a > release function. Now we have the release, but its name really doesn't > scream that it's the inverse of map_pin. Is it too late to rename map > to acquire? (I'm not too wed to the 'acquire' name, 'allocate' would > also be a good candidate. We also considered 'reserve' but that had > less of a "now I own it exclusively" feel to it. 'map' didn't feel > quite right because mapping pins in an FDT world is the responsibility > of the pinmux driver, not a gpio thing.) I do not think it's too late. I guess if you do this before code slush for 11 that should be OK. At least I can not come up with a reason why it can't be done. -- gonzo ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r299563 - head/sys/dev/gpio
On Thu, May 12, 2016 at 5:40 PM, Ian Lepore wrote: > On Thu, 2016-05-12 at 20:12 +, Oleksandr Tymoshenko wrote: >> Author: gonzo >> Date: Thu May 12 20:12:45 2016 >> New Revision: 299563 >> URL: https://svnweb.freebsd.org/changeset/base/299563 >> >> Log: >> Add gpiobus_release_pin function to release mapped pin >> >> Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. >> Without it >> it's impossible to properly release pin so if kernel module is >> reloaded >> it can't re-use pins again > > This reminds me that we (Michael Meloun & I) had talked on irc about > renaming gpiobus_map_pin() to gpiobus_acquire_pin() and adding a > release function. Now we have the release, but its name really doesn't > scream that it's the inverse of map_pin. Is it too late to rename map > to acquire? (I'm not too wed to the 'acquire' name, 'allocate' would > also be a good candidate. We also considered 'reserve' but that had > less of a "now I own it exclusively" feel to it. 'map' didn't feel > quite right because mapping pins in an FDT world is the responsibility > of the pinmux driver, not a gpio thing.) I don't think it is too late for this change, actually I think we are right on time to fill the gaps (just another term to 'fix my bugs'...). Luiz ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r299563 - head/sys/dev/gpio
On Thu, 2016-05-12 at 20:12 +, Oleksandr Tymoshenko wrote: > Author: gonzo > Date: Thu May 12 20:12:45 2016 > New Revision: 299563 > URL: https://svnweb.freebsd.org/changeset/base/299563 > > Log: > Add gpiobus_release_pin function to release mapped pin > > Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. > Without it > it's impossible to properly release pin so if kernel module is > reloaded > it can't re-use pins again This reminds me that we (Michael Meloun & I) had talked on irc about renaming gpiobus_map_pin() to gpiobus_acquire_pin() and adding a release function. Now we have the release, but its name really doesn't scream that it's the inverse of map_pin. Is it too late to rename map to acquire? (I'm not too wed to the 'acquire' name, 'allocate' would also be a good candidate. We also considered 'reserve' but that had less of a "now I own it exclusively" feel to it. 'map' didn't feel quite right because mapping pins in an FDT world is the responsibility of the pinmux driver, not a gpio thing.) -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r299563 - head/sys/dev/gpio
Author: gonzo
Date: Thu May 12 20:12:45 2016
New Revision: 299563
URL: https://svnweb.freebsd.org/changeset/base/299563
Log:
Add gpiobus_release_pin function to release mapped pin
Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. Without it
it's impossible to properly release pin so if kernel module is reloaded
it can't re-use pins again
Modified:
head/sys/dev/gpio/gpiobus.c
head/sys/dev/gpio/gpiobusvar.h
Modified: head/sys/dev/gpio/gpiobus.c
==
--- head/sys/dev/gpio/gpiobus.c Thu May 12 20:04:09 2016(r299562)
+++ head/sys/dev/gpio/gpiobus.c Thu May 12 20:12:45 2016(r299563)
@@ -281,6 +281,30 @@ gpiobus_map_pin(device_t bus, uint32_t p
return (0);
}
+/* Release mapped pin */
+int
+gpiobus_release_pin(device_t bus, uint32_t pin)
+{
+ struct gpiobus_softc *sc;
+
+ sc = device_get_softc(bus);
+ /* Consistency check. */
+ if (pin >= sc->sc_npins) {
+ device_printf(bus,
+ "gpiobus_map_pin: invalid pin %d, max=%d\n",
+ pin, sc->sc_npins - 1);
+ return (-1);
+ }
+
+ if (!sc->sc_pins[pin].mapped) {
+ device_printf(bus, "gpiobus_map_pin: pin %d is not mapped\n",
pin);
+ return (-1);
+ }
+ sc->sc_pins[pin].mapped = 0;
+
+ return (0);
+}
+
static int
gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int mask)
{
Modified: head/sys/dev/gpio/gpiobusvar.h
==
--- head/sys/dev/gpio/gpiobusvar.h Thu May 12 20:04:09 2016
(r299562)
+++ head/sys/dev/gpio/gpiobusvar.h Thu May 12 20:12:45 2016
(r299563)
@@ -138,6 +138,7 @@ int gpiobus_init_softc(device_t);
int gpiobus_alloc_ivars(struct gpiobus_ivar *);
void gpiobus_free_ivars(struct gpiobus_ivar *);
int gpiobus_map_pin(device_t, uint32_t);
+int gpiobus_release_pin(device_t, uint32_t);
extern driver_t gpiobus_driver;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
