From 77188e41f5c9966432a0fbb3bffd2069d53cc608 Mon Sep 17 00:00:00 2001 From: Aidan MacDonald Date: Sun, 25 Apr 2021 14:17:45 +0100 Subject: X1000: remove bogus GPIO Z mutex There's absolutely no way for gpio_config() to get called from two different threads due to the co-operative threading model, and it is unsafe to call from IRQ context no matter what we do. Change-Id: I58f7d1f68c7a414610bb020e26b774cb1015a3b0 --- firmware/target/mips/ingenic_x1000/gpio-x1000.h | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) (limited to 'firmware/target/mips/ingenic_x1000/gpio-x1000.h') diff --git a/firmware/target/mips/ingenic_x1000/gpio-x1000.h b/firmware/target/mips/ingenic_x1000/gpio-x1000.h index f1a65b37b5..cfbe86338a 100644 --- a/firmware/target/mips/ingenic_x1000/gpio-x1000.h +++ b/firmware/target/mips/ingenic_x1000/gpio-x1000.h @@ -26,12 +26,11 @@ * -------- * * To assign a new function to a GPIO, call gpio_config(). This uses the - * hardware's GPIO Z facility to atomically most GPIO registers at once, + * hardware's GPIO Z facility to atomically set most GPIO registers at once, * so it can be used to make any state transition safely. Since GPIO Z is - * protected by a mutex, you can't call gpio_config() from interrupt context. - * - * If you need to use GPIO Z directly, then use gpio_lock() and gpio_unlock() - * to acquire the mutex. + * a global hardware resource, it is unsafe to call gpio_config() from IRQ + * context -- if the interrupted code was also running gpio_config(), then + * the results would be unpredictable. * * Depending on the current GPIO state, certain state transitions are safe to * perform without locking, as they only change one register: @@ -74,8 +73,6 @@ #define GPIO_IRQ_EDGE(i) (0x1e|((i)&1)) extern void gpio_init(void); -extern void gpio_lock(void); -extern void gpio_unlock(void); extern void gpio_config(int port, unsigned pinmask, int func); static inline void gpio_out_level(int port, unsigned pinmask, int level) -- cgit v1.2.3